On Wed, Dec 13, 2000 at 11:11:55PM +0100, Andi Kleen wrote:
> Perhaps it should mention that the guaranteed useful range of atomic_t
> is only 24bit ? Documentation without source would rather useless if it
> didn't mention such pitfalls.
Does
ftp://people.redhat.com/twaugh/patches/linux24/lin
On Wed, Dec 13, 2000 at 07:23:52PM +, Tim Waugh wrote:
> + * atomic_add - add integer to atomic variable
> + * @i: integer value to add
> + * @v: pointer of type atomic_t
> + *
> + * Atomically adds @i to @v.
Perhaps it should mention that the guaranteed useful range of atomic_t
is only 24b
On Thu, Dec 07, 2000 at 09:59:18PM -0500, Alexander Viro wrote:
> On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> > > BTW, could we finally lose mpx(2)?
> >
> > Maybe we lost it - I find sys_mpx only in a comment in arch/arm/kernel/calls.S
>
> Sure, but man2/mpx.2 is alive and well...
manpages-de
On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> > BTW, if you still have 1.7, 1.10, 1.13 and 1.14...
>
> See ftp://ftp.cwi.nl/pub/aeb/manpages/ (will soon disappear again).
Got them, thanks.
> > BTW, could we finally lose mpx(2)?
>
> Maybe we lost it - I find sys_mpx only in a comment in arch
> BTW, if you still have 1.7, 1.10, 1.13 and 1.14...
See ftp://ftp.cwi.nl/pub/aeb/manpages/ (will soon disappear again).
> BTW, could we finally lose mpx(2)?
Maybe we lost it - I find sys_mpx only in a comment in arch/arm/kernel/calls.S
Andries
-
To unsubscribe from this list: send the line "u
On Thu, 7 Dec 2000, Andries Brouwer wrote:
> On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
>
> > Al, currently walking through the /usr/share/man/man2 and swearing silently...
>
> Swearing? At the POSIX decisions or at the man page quality?
Mostly at the out-of-sync/not-all
On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote:
> Al, currently walking through the /usr/share/man/man2 and swearing silently...
Swearing? At the POSIX decisions or at the man page quality?
In the latter case, additions and corrections are very welcome.
Make sure that you have 1.
On Thu, Dec 07, 2000 at 08:23:59AM -0500, Alexander Viro wrote:
>
> Oh, lovely - where the hell had the following come from?
> % man truncate
> ...
>EINVAL The pathname contains a character with the high-
> order bit set.
> ...
> Andries, would you mind removing that, er
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> yet. So far you only said that a different implementation, i.e. a
> different place to put the checks, is preferrable.
-EPERM returned by permission() if we ask for write access to immutable.
Al, currently walking through the /usr/share/man/man2 an
On Thu, 7 Dec 2000, Alexander Viro wrote:
> On Thu, 7 Dec 2000, Tigran Aivazian wrote:
>
> > The rationale for being compatible with 4.4BSD on append-only but not on
> > immutable is -- for immutable we can do the test by means of permission()
> > fast but for append-only we would need an extra i
On Thu, 7 Dec 2000, Alexander Viro wrote:
> So correct solution may very well be to change the return value of
> permission(9). FWIW, MAY_TRUNCATE might be a good idea - notice that
> knfsd already has something like that. It makes sense for directories,
> BTW - having may_delete() drop the IS_APP
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> The rationale for being compatible with 4.4BSD on append-only but not on
> immutable is -- for immutable we can do the test by means of permission()
> fast but for append-only we would need an extra if() above permission so
> let's just be BSD-compat
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
> a) we don't hit that test because permission takes care of it (for
> regulars/dirs/symlinks but here only regulars are important)
omit what is in brackets but everything in email and the patch itself are
valid and tested. The detail in bracket above wa
On Wed, 6 Dec 2000, Alexander Viro wrote:
> On Wed, 6 Dec 2000, Linus Torvalds wrote:
> > Why remove the EROFS test?
>
> there, so if it's not a regular file we die before the call of permission(),
> if it is and fs is readonly - we get -EROFS from permission() and die
> there. In either case we d
On Wed, 6 Dec 2000, Linus Torvalds wrote:
>
>
> On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> >
> > This patch combines your previous patch with 2 changes I have just
> > suggested. Both changes are obvious (and correct).
>
> Why remove the EROFS test?
Tigran has a point - permission() does
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
>
> This patch combines your previous patch with 2 changes I have just
> suggested. Both changes are obvious (and correct).
Why remove the EROFS test?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> (correction to my previous message -- the immutable thing to return
EPERM
~
I meant EACCES. And I think Linux does the right thing but FreeBSD is
broken. The rationale is in the definition of EACCES and EPERM, taken from
SuSv2 (and why would you le
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> The question is whether or not it is worth taking a lock again (with
> that non-zero cost) to achieve the gain of doing the 92-byte memset and
> the atomic_set in parallel with other CPUs. In other words, by locking
> and unlocking twice, you reduce th
[Peter Samuelson]
> > Whether a memset of 92 bytes (on 32-bit arch), plus an
> > atomic_set(), are worth deserializing, I do not know.
[Tigran Aivazian]
> Of course, they are worth it. Actually, I don't understand how can
> you even doubt it?
Clearly we are talking at cross-purposes here. I
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > The only reason one could think of was to "hold the lock for as short
> > time as possible" but a minute's thought reveals that such reason is
> > invalid (i.e. one is more likely to waste time spinning on the lock
> > than to save
[Tigran Aivazian]
> The only reason one could think of was to "hold the lock for as short
> time as possible" but a minute's thought reveals that such reason is
> invalid (i.e. one is more likely to waste time spinning on the lock
> than to save it by dropping/retaking it, given the relative dura
On Sun, 3 Dec 2000, Matti Aarnio wrote:
> On Sat, Dec 02, 2000 at 10:11:28PM +, Tigran Aivazian wrote:
> > Second attempt. The linux-kernel list is broken at the moment (reported
> > fault to postmaster already) so some messages get lost at random:
>
>Tigran has local problems with his o
On Sat, Dec 02, 2000 at 10:11:28PM +, Tigran Aivazian wrote:
> Second attempt. The linux-kernel list is broken at the moment (reported
> fault to postmaster already) so some messages get lost at random:
Tigran has local problems with his outgoing email.
Nothing to do with vger.kernel.or
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> --- linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c.origSat Dec 2 16:18:05
>2000
> +++ linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c Sat Dec 2 16:19:04 2000
> @@ -228,6 +228,6 @@
> }
>
> struct ip_conntrack_protocol ip_conntrack_
Tigran Aivazian wrote:
>
> On Sat, 2 Dec 2000, Tigran Aivazian wrote:
>
> > On Sat, 2 Dec 2000, H. Peter Anvin wrote:
> > >
> > > OK, fair enough. Let me make a new statement then: I suggest we preface
> > > these with MSR_ anyway so we can tell what they really are.
> > >
> >
> > That is much
Tigran Aivazian wrote:
>
> On Sat, 2 Dec 2000, H. Peter Anvin wrote:
> >
> > OK, fair enough. Let me make a new statement then: I suggest we preface
> > these with MSR_ anyway so we can tell what they really are.
> >
>
> That is much better. Actually, I accept your suggestion. (because I have
>
Tigran Aivazian wrote:
>
> On Sat, 2 Dec 2000, H. Peter Anvin wrote:
>
> > Alan Cox wrote:
> > >
> > > > Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> > > > besides, the preferred prefix in existing locations in the Linux
> > > > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_
Alan Cox wrote:
>
> > Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> > besides, the preferred prefix in existing locations in the Linux
> > kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE. I think there
>
> I think I agree with Tigran's naming. These are IA32 registers
On 1 Dec 2000, H. Peter Anvin wrote:
> > +/* symbolic names for some interesting MSRs */
> > +#define IA32_PLATFORM_ID 0x17
> > +#define IA32_UCODE_WRITE 0x79
> > +#define IA32_UCODE_REV 0x8B
> >
>
> Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> besides, the
> Please call these MSR_* instead, "IA32_*" isn't very descriptive,
> besides, the preferred prefix in existing locations in the Linux
> kernel is "X86_", e.g. X86_EFLAGS_IF or X86_CR4_PSE. I think there
I think I agree with Tigran's naming. These are IA32 registers not X86 ones ;)
-
To unsubs
Followup to: <[EMAIL PROTECTED]>
By author:Tigran Aivazian <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Second attempt -- the first one got lost due to some local mail client
> problems...
>
> Hi Linus,
>
> Here is the patch to microcode update driver to support the new P4
> CPU.
31 matches
Mail list logo
