--- linux-2.4.0-t12.vanilla+reiser/drivers/Makefile Thu Dec 21 12:52:17 2000
+++ linux-2.4.0-t12/drivers/MakefileSun Dec 31 00:38:09 2000
@@ -42,6 +42,7 @@
subdir-$(CONFIG_HAMRADIO) += net/hamradio
subdir-$(CONFIG_ACPI) += acpi
+subdir-$(CONFIG_I2C) += i2c
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
Linus,
Here is a patch from Armin Kuster which adds inline documentation to
some macros.
Tim.
*/
2000-12-13 Tim Waugh <[EMAIL PROTECTED]>
* include/linux/init.h, include/linux/module.h: Inline
documentation for some macros. Patch from Armin Kuster.
--- linux-2.4.0-test12/in
Hi Linus,
If misc registration fails but devfs registration succeeds then we should
return 0 from microcode_init.
Regards,
Tigran
--- linux/arch/i386/kernel/microcode.c Tue Dec 12 09:25:10 2000
+++ work/arch/i386/kernel/microcode.c Tue Dec 12 09:55:28 2000
@@ -126,6 +126,7 @@
Hi Linus,
Unfortunately there was a SMP race between ->read() and ->ioctl() routines
(thanks to Mark Hemment for pointing this out!). If one was inside the
->read() after the EOF check and an ioctl requests came in onother CPU
which freed the memory and reset the size then one could panic. The fi
Hi Linus,
I have just found and fixed another bug in the driver -- the
->ioctl() method would print "freed 0 bytes" when it actually freed >0, if
the update has failed previously.
The patch is cumulative, i.e. contains all the previous fixes I have sent
to you in the last few days.
Tested thoro
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
Hi ALexander,
This patch combines your previous patch with 2 changes I have just
suggested. Both changes are obvious (and correct).
(correction to my previous message -- the immutable thing to return EPERM
is not just a good idea, it is imperative and Linux already does that --
so we can drop th
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
Hi Linus,
It is quite clear that dropping and retaking the files_lock in
fs/file_table.c:get_empty_filp() at the label new_one is absolutely
unnecessary. 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 inva
Hi Linus,
This patch adds support for the latest member of Intel IA32 family -- the
Pentium 4 processor. Tested under 2.4.0-test12-pre4 -- still works.
Regards,
Tigran
diff -urN -X dontdiff linux/CREDITS ucode/CREDITS
--- linux/CREDITS Mon Dec 4 08:43:33 2000
+++ ucode/CREDITS Mon
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_
--- linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c.orig Sat 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_protocol_tcp
-= { { NULL, NULLpkt_IPPROTO_TCP, "tcp",
-
Second attempt. The linux-kernel list is broken at the moment (reported
fault to postmaster already) so some messages get lost at random:
-- Forwarded message --
Date: Sat, 2 Dec 2000 21:49:21 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTEC
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.
Second attempt -- the first one got lost due to some local mail client
problems...
-- Forwarded message --
Date: Fri, 1 Dec 2000 11:43:10 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject:
Attached patch fixes the BUG() people are seeing when using the ntfs
driver with 2.4.0-test* kernels. Patch is tested and everything seems to
be working fine with it.
Description:
The BUG() call was due to a not implemented ntfs_get_block().
The fix is to comment out all [bm]map associated cod
43 matches
Mail list logo
