SLUB under lguest on i386
Tried to boot using SLUB under lguest with 2.6.21-mm2. Got the following: ... [0.388000] NET: Registered protocol family 17 [0.388000] Using IPI Shortcut mode [0.42] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended [0.42] VFS: Mounted root (ext2 filesystem). [0.42] Freeing unused kernel memory: 188k freed [ 17.536000] BUG: spinlock lockup on CPU#0, init/1, c17de0c0 [ 17.536000] [] show_trace_log_lvl+0x1a/0x30 [ 17.536000] [] show_trace+0x12/0x14 [ 17.536000] [] dump_stack+0x15/0x17 [ 17.536000] [] _raw_spin_lock+0xbf/0xd8 [ 17.536000] [] _spin_lock+0x3c/0x42 [ 17.536000] [] vma_adjust+0x1a9/0x35f [ 17.536000] [] vma_merge+0x158/0x168 [ 17.536000] [] mmap_region+0x13b/0x405 [ 17.536000] [] do_mmap_pgoff+0x211/0x269 [ 17.536000] [] sys_mmap2+0x64/0xb4 [ 17.536000] [] old_mmap+0x59/0x5f [ 17.536000] [] syscall_call+0x7/0xb [ 17.536000] === And no sign of further progress. SLAB worked fine. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SLUB under lguest on i386
Tried to boot using SLUB under lguest with 2.6.21-mm2. Got the following: ... [0.388000] NET: Registered protocol family 17 [0.388000] Using IPI Shortcut mode [0.42] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended [0.42] VFS: Mounted root (ext2 filesystem). [0.42] Freeing unused kernel memory: 188k freed [ 17.536000] BUG: spinlock lockup on CPU#0, init/1, c17de0c0 [ 17.536000] [c0104584] show_trace_log_lvl+0x1a/0x30 [ 17.536000] [c0105196] show_trace+0x12/0x14 [ 17.536000] [c0105222] dump_stack+0x15/0x17 [ 17.536000] [c021339f] _raw_spin_lock+0xbf/0xd8 [ 17.536000] [c03cd41a] _spin_lock+0x3c/0x42 [ 17.536000] [c0154f0c] vma_adjust+0x1a9/0x35f [ 17.536000] [c01554c3] vma_merge+0x158/0x168 [ 17.536000] [c0155b3b] mmap_region+0x13b/0x405 [ 17.536000] [c01560ec] do_mmap_pgoff+0x211/0x269 [ 17.536000] [c0107594] sys_mmap2+0x64/0xb4 [ 17.536000] [c010763d] old_mmap+0x59/0x5f [ 17.536000] [c0103ed0] syscall_call+0x7/0xb [ 17.536000] === And no sign of further progress. SLAB worked fine. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel headers violate RFC2553
On 8 Jun 2001, Linus Torvalds wrote: > The basic issue is that the kernel will _refuse_ to follow the > "namespace of the day" rules of C89, C99, POSIX, BSD, SuS, GNU .. the > list goes on. The kernel headers are not meant to be used in user space, > and will not have the strict namespace rules that a lot of standards > spend so much time playing with. Add something like this to linux/config.h in 2.5? #if !defined(__KERNEL__) || !defined(__KERNEL_ME_HARDER__) #warning "Using kernel headers in userspace apps is unsupported." #warning "Don't come crying to us when it breaks." #endif -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux kernel headers violate RFC2553
On 8 Jun 2001, Linus Torvalds wrote: The basic issue is that the kernel will _refuse_ to follow the namespace of the day rules of C89, C99, POSIX, BSD, SuS, GNU .. the list goes on. The kernel headers are not meant to be used in user space, and will not have the strict namespace rules that a lot of standards spend so much time playing with. Add something like this to linux/config.h in 2.5? #if !defined(__KERNEL__) || !defined(__KERNEL_ME_HARDER__) #warning Using kernel headers in userspace apps is unsupported. #warning Don't come crying to us when it breaks. #endif -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
On Wed, 30 May 2001, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn > > 'DoC_Probe' calling init fn 'doccheck' > > Strictly speaking, not actually a bug. DoC_Probe() itself is only ever > called from __init code. But it's probably not worth trying to make the > checker notice that situation - I've fixed it anyway by making DoC_Probe() > __init too, which saves a bit more memory. Thanks. Anything that's only called or used by functions marked init is a candidate for being marked init. I suspect there's still quite a bit out there that meets this description. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 2.4.5-ac4 non-init functions calling init functions
On Wed, 30 May 2001, David Woodhouse wrote: [EMAIL PROTECTED] said: drivers/mtd/docprobe.c:195:DoC_Probe: ERROR:INIT: non-init fn 'DoC_Probe' calling init fn 'doccheck' Strictly speaking, not actually a bug. DoC_Probe() itself is only ever called from __init code. But it's probably not worth trying to make the checker notice that situation - I've fixed it anyway by making DoC_Probe() __init too, which saves a bit more memory. Thanks. Anything that's only called or used by functions marked init is a candidate for being marked init. I suspect there's still quite a bit out there that meets this description. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Thu, 24 May 2001, Marko Kreen wrote: > On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote: > > Daniel Phillips wrote: > > > > > It's going to be marked 'd', it's a directory, not a file. > > > > > > > > Aha. So you lose the S_ISCHR/BLK attribute. > > > > > > Readdir fills in a directory type, so ls sees it as a directory and does > > > the right thing. On the other hand, we know we're on a device > > > filesystem so we will next open the name as a regular file, and find > > > ISCHR or ISBLK: good. > > > > ??? The kernel may know it, but the app? Or do you really want to > > give different stat data on stat(2) and fstat(2)? These flags are > > currently used by archive/backup prgs. It's a hint that these files > > are not regular files and shouldn't be opened for reading. > > Having a 'd' would mean that they would really try to enter the > > directory and save it's contents. Don't know what happens in this > > case to your "special" files ;-) > > IMHO the CHR/BLK is not needed. Think of /proc. In the future, > the backup tools will be told to ignore /dev, that's all. The /dev dir should not be special. At least not to the kernel. I have device files in places other than /dev, and you probably do too (hint: anonymous FTP). -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Thu, 24 May 2001, Marko Kreen wrote: On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote: Daniel Phillips wrote: It's going to be marked 'd', it's a directory, not a file. Aha. So you lose the S_ISCHR/BLK attribute. Readdir fills in a directory type, so ls sees it as a directory and does the right thing. On the other hand, we know we're on a device filesystem so we will next open the name as a regular file, and find ISCHR or ISBLK: good. ??? The kernel may know it, but the app? Or do you really want to give different stat data on stat(2) and fstat(2)? These flags are currently used by archive/backup prgs. It's a hint that these files are not regular files and shouldn't be opened for reading. Having a 'd' would mean that they would really try to enter the directory and save it's contents. Don't know what happens in this case to your special files ;-) IMHO the CHR/BLK is not needed. Think of /proc. In the future, the backup tools will be told to ignore /dev, that's all. The /dev dir should not be special. At least not to the kernel. I have device files in places other than /dev, and you probably do too (hint: anonymous FTP). -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Wed, 23 May 2001, Daniel Phillips wrote: > > > > *boggle* > > > > > > > >[general sense of unease] > > > > I fully agree with Oliver. It's an abomination. > > We are, or at least, I am, investigating this question purely on > technical grounds - name calling is a noop. I'd be happy to find a > real reason why this is a bad idea but so far none has been > presented. I will agree that the thing can be done in principle. You're not going to find anyone who's going to argue that part. All other things being equal, I actually think it's a neat idea. The part that is a problem is people, namely people who write programs. They've had decades to expect that directories are not also files, and if they happen to do things like check whether a file is not a directory before opening it, it's _our fault_ if they get confused. Consider the recent subtle change to fork() that was reversed because it uncovered an unforseen bug in bash. The proposed change is not at all subtle, is entirely without precedent, and is likely to break much. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Wed, 23 May 2001, Daniel Phillips wrote: *boggle* [general sense of unease] I fully agree with Oliver. It's an abomination. We are, or at least, I am, investigating this question purely on technical grounds - name calling is a noop. I'd be happy to find a real reason why this is a bad idea but so far none has been presented. I will agree that the thing can be done in principle. You're not going to find anyone who's going to argue that part. All other things being equal, I actually think it's a neat idea. The part that is a problem is people, namely people who write programs. They've had decades to expect that directories are not also files, and if they happen to do things like check whether a file is not a directory before opening it, it's _our fault_ if they get confused. Consider the recent subtle change to fork() that was reversed because it uncovered an unforseen bug in bash. The proposed change is not at all subtle, is entirely without precedent, and is likely to break much. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Guest section DW wrote: > On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote: > > > > >+ struct list_headhash; > > > > Why not name consistently with the struct block_device? > > > struct list_headcd_hash; > > > Because foo_ is a throwback to the days when C compilers had a single > > namespace for all structure elements, not a readability aid. If you need > > foo_ to know what type of structure you're futzing with, you need to name > > your variables better. > > One often has to go through all occurrences of a variable or > field of a struct. That is much easier with cd_hash and cd_dev > than with hash and dev. > > No, it is a good habit, these prefixes, even though it is no longer > necessary because of the C compiler. A better habit is encapsulating your data structures well enough that the entire kernel doesn't feel the need to go digging through them. The fact that you have to change many widely-scattered instances of something points to bad modularity. Supporting that practice with verbose naming is not doing yourself a favor in the long run. If you must, use accessor functions instead. At best you'll be able to make sweeping semantic changes in one spot. At worst, you'll be able to grep for it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Tue, 22 May 2001, Daniel Phillips wrote: > > I don't think it's likely to be even workable. Just consider the > > directory entry for a moment - is it going to be marked d or [cb]? > > It's going to be marked 'd', it's a directory, not a file. Are we talking about the same proposal? The one where I can open /dev/dsp and /dev/dsp/ctl? But I can still do 'cat /dev/hda > /dev/dsp'? It's still a file. If it's not a file anymore, it ain't UNIX. > > If it doesn't have the directory bit set, Midnight commander won't > > let me look at it, and I wouldn't blame cd or ls for complaining. If it > > does have the 'd' bit set, I wouldn't blame cp, tar, find, or a > > million other programs if they did the wrong thing. They've had 30 > > years to expect that files aren't directories. They're going to act > > weird. > > No problem, it's a directory. > > > Linus has been kicking this idea around for a couple years now and > > it's still a cute solution looking for a problem. It just doesn't > > belong in UNIX. > > Hmm, ok, do we still have any *technical* reasons? If you define *technical* to not include design, sure. Oh, did I mention unnecessary, solvable in userspace? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Alexander Viro wrote: > On Tue, 22 May 2001, Oliver Xymoron wrote: > > > Because foo_ is a throwback to the days when C compilers had a single > > namespace for all structure elements, not a readability aid. If you need > > foo_ to know what type of structure you're futzing with, you need to name > > your variables better. > > Not always. If the thing is used all over the tree, it'd better be > greppable. I hate the foo->de stuff - it's not localized and it's > impossible to grep for. I'd like to say the compiler will happily find it for you, but the kernel's mostly conditionally compiled.. Have you tried something like: find -type f | xargs grep -A100 'struct_name' | grep -e '\belement\b' Obviously not a fix, but possibly helpful. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Anton Altaparmakov wrote:
> Hello,
>
> At 15:18 22/05/01, Alexander Viro wrote:
> [snip cool stuff]
> >+struct char_device {
> >+ struct list_headhash;
> >+ atomic_tcount;
> >+ dev_t dev;
> >+ atomic_topeners;
> >+ struct semaphoresem;
>
> Why not name consistently with the struct block_device?
> I.e.:
> struct char_device {
> struct list_headcd_hash;
> atomic_tcd_count;
> dev_t cd_dev;
> atomic_tcd_openers;
> struct semaphorecd_sem;
> };
Because foo_ is a throwback to the days when C compilers had a single
namespace for all structure elements, not a readability aid. If you need
foo_ to know what type of structure you're futzing with, you need to name
your variables better.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Alexander Viro wrote: > On Mon, 21 May 2001, Linus Torvalds wrote: > > > It shouldn't be impossible to do the same thing to ioctl numbers. Nastier, > > yes. No question about it. But we don't necessarily have to redesign the > > whole approach - we only want to re-design the internal kernel interfaces. > > > > That, in turn, might be as simple as changing the ioctl incoming arguments > > of into a structure like . > > drivers/net/ppp_generic.c: > > And that's far from being uncommon. They _do_ follow pointers. Some - more > than once. Doesn't matter. If we make doing it right substantially easier than doing it wrong, then people will quit doing it wrong. And it'll be much easier to spot the ugly hacks in patches. I actually wrote the above a while back.. lessee.. where's that thread.. http://mlarchive.ima.com/linux-kernel/1999/Jan/4932.html The end result was using the resource trees to hold pointers to functions with prototypes like the above (plus file handle info). No more giant grotty switch statements (though you could keep those if you wanted - just point all your ioctls to the same old function). Why trees? To implement inheritance of ioctls through the device hierarchy. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Mon, 21 May 2001, Daniel Phillips wrote: > On Monday 21 May 2001 19:16, Oliver Xymoron wrote: > > What I'd like to see: > > > > - An interface for registering an array of related devices (almost > > always two: raw and ctl) and their legacy device numbers with a > > single userspace callout that does whatever /dev/ creation needs to > > be done. Thus, naming and permissions live in user space. No "device > > node is also a directory" weirdness... > > Could you be specific about what is weird about it? *boggle* Without precedent in any other UNIX? Or other operating systems, for that matter? Can you honestly say it doesn't strike you as weird? It's beating the least surprise rule with a big stick, fercryinoutloud. Ok, so technically UNIX directories were once just files. But it's been a long time since people thought exposing that implementation detail was a good idea, and anyway, it's the opposite situation (and no longer true on modern fses). I don't think it's likely to be even workable. Just consider the directory entry for a moment - is it going to be marked d or [cb]? If it doesn't have the directory bit set, Midnight commander won't let me look at it, and I wouldn't blame cd or ls for complaining. If it does have the 'd' bit set, I wouldn't blame cp, tar, find, or a million other programs if they did the wrong thing. They've had 30 years to expect that files aren't directories. They're going to act weird. Linus has been kicking this idea around for a couple years now and it's still a cute solution looking for a problem. It just doesn't belong in UNIX. More importantly, there's no call for the weirdness. Look, we've already got to have a userspace callout for new devices so that we can do config, firmware downloading, automounting, etc. There's no reason we can't stick the rest of the dynamic /dev/ magic in userspace with the same mechanism. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Mon, 21 May 2001, Daniel Phillips wrote: On Monday 21 May 2001 19:16, Oliver Xymoron wrote: What I'd like to see: - An interface for registering an array of related devices (almost always two: raw and ctl) and their legacy device numbers with a single userspace callout that does whatever /dev/ creation needs to be done. Thus, naming and permissions live in user space. No device node is also a directory weirdness... Could you be specific about what is weird about it? *boggle* Without precedent in any other UNIX? Or other operating systems, for that matter? Can you honestly say it doesn't strike you as weird? It's beating the least surprise rule with a big stick, fercryinoutloud. Ok, so technically UNIX directories were once just files. But it's been a long time since people thought exposing that implementation detail was a good idea, and anyway, it's the opposite situation (and no longer true on modern fses). I don't think it's likely to be even workable. Just consider the directory entry for a moment - is it going to be marked d or [cb]? If it doesn't have the directory bit set, Midnight commander won't let me look at it, and I wouldn't blame cd or ls for complaining. If it does have the 'd' bit set, I wouldn't blame cp, tar, find, or a million other programs if they did the wrong thing. They've had 30 years to expect that files aren't directories. They're going to act weird. Linus has been kicking this idea around for a couple years now and it's still a cute solution looking for a problem. It just doesn't belong in UNIX. More importantly, there's no call for the weirdness. Look, we've already got to have a userspace callout for new devices so that we can do config, firmware downloading, automounting, etc. There's no reason we can't stick the rest of the dynamic /dev/ magic in userspace with the same mechanism. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, 21 May 2001, Alexander Viro wrote: On Mon, 21 May 2001, Linus Torvalds wrote: It shouldn't be impossible to do the same thing to ioctl numbers. Nastier, yes. No question about it. But we don't necessarily have to redesign the whole approach - we only want to re-design the internal kernel interfaces. That, in turn, might be as simple as changing the ioctl incoming arguments of cmd,arg into a structure like type,cmd,inbuf,inlen,outbuf,outlen. drivers/net/ppp_generic.c: And that's far from being uncommon. They _do_ follow pointers. Some - more than once. Doesn't matter. If we make doing it right substantially easier than doing it wrong, then people will quit doing it wrong. And it'll be much easier to spot the ugly hacks in patches. I actually wrote the above a while back.. lessee.. where's that thread.. http://mlarchive.ima.com/linux-kernel/1999/Jan/4932.html The end result was using the resource trees to hold pointers to functions with prototypes like the above (plus file handle info). No more giant grotty switch statements (though you could keep those if you wanted - just point all your ioctls to the same old function). Why trees? To implement inheritance of ioctls through the device hierarchy. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Anton Altaparmakov wrote:
Hello,
At 15:18 22/05/01, Alexander Viro wrote:
[snip cool stuff]
+struct char_device {
+ struct list_headhash;
+ atomic_tcount;
+ dev_t dev;
+ atomic_topeners;
+ struct semaphoresem;
Why not name consistently with the struct block_device?
I.e.:
struct char_device {
struct list_headcd_hash;
atomic_tcd_count;
dev_t cd_dev;
atomic_tcd_openers;
struct semaphorecd_sem;
};
Because foo_ is a throwback to the days when C compilers had a single
namespace for all structure elements, not a readability aid. If you need
foo_ to know what type of structure you're futzing with, you need to name
your variables better.
--
Love the dolphins, she advised him. Write by W.A.S.T.E..
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Alexander Viro wrote: On Tue, 22 May 2001, Oliver Xymoron wrote: Because foo_ is a throwback to the days when C compilers had a single namespace for all structure elements, not a readability aid. If you need foo_ to know what type of structure you're futzing with, you need to name your variables better. Not always. If the thing is used all over the tree, it'd better be greppable. I hate the foo-de stuff - it's not localized and it's impossible to grep for. I'd like to say the compiler will happily find it for you, but the kernel's mostly conditionally compiled.. Have you tried something like: find -type f | xargs grep -A100 'struct_name' | grep -e '\belement\b' Obviously not a fix, but possibly helpful. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct char_device
On Tue, 22 May 2001, Guest section DW wrote: On Tue, May 22, 2001 at 11:08:16AM -0500, Oliver Xymoron wrote: + struct list_headhash; Why not name consistently with the struct block_device? struct list_headcd_hash; Because foo_ is a throwback to the days when C compilers had a single namespace for all structure elements, not a readability aid. If you need foo_ to know what type of structure you're futzing with, you need to name your variables better. One often has to go through all occurrences of a variable or field of a struct. That is much easier with cd_hash and cd_dev than with hash and dev. No, it is a good habit, these prefixes, even though it is no longer necessary because of the C compiler. A better habit is encapsulating your data structures well enough that the entire kernel doesn't feel the need to go digging through them. The fact that you have to change many widely-scattered instances of something points to bad modularity. Supporting that practice with verbose naming is not doing yourself a favor in the long run. If you must, use accessor functions instead. At best you'll be able to make sweeping semantic changes in one spot. At worst, you'll be able to grep for it. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Tue, 22 May 2001, Daniel Phillips wrote: I don't think it's likely to be even workable. Just consider the directory entry for a moment - is it going to be marked d or [cb]? It's going to be marked 'd', it's a directory, not a file. Are we talking about the same proposal? The one where I can open /dev/dsp and /dev/dsp/ctl? But I can still do 'cat /dev/hda /dev/dsp'? It's still a file. If it's not a file anymore, it ain't UNIX. If it doesn't have the directory bit set, Midnight commander won't let me look at it, and I wouldn't blame cd or ls for complaining. If it does have the 'd' bit set, I wouldn't blame cp, tar, find, or a million other programs if they did the wrong thing. They've had 30 years to expect that files aren't directories. They're going to act weird. No problem, it's a directory. Linus has been kicking this idea around for a couple years now and it's still a cute solution looking for a problem. It just doesn't belong in UNIX. Hmm, ok, do we still have any *technical* reasons? If you define *technical* to not include design, sure. Oh, did I mention unnecessary, solvable in userspace? -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > K - so what? I'm guessing what you want me to see is that these
> > implement multiple channels. Is there a reason that eia001stat couldn't be
> > implemented as
> >
> > f=open("/dev/eia001ctl",O_RDWR);
> > write(f,"stat\n");
> > status=read(f); /* returns "stat foo\n" */
>
> Less convenient.
True enough.
> > We don't want to implement a separate device node for every OOB ioctl that
> > returns data, do we? Why should stat be any different?
>
> For every? Probably not. Forcing all of them together? I bet that in many
> cases it will be damn inconvenient. You are forcing the policy on all
> drivers. For no good reason, AFAICS.
No - I'm merely pointing out that it's sufficient. And I'm pretty sure we
want to make additional control or stream interfaces the exception rather
than the rule. And having a standard read and write protocol of some sort
for ctl devices is more or less mandatory, otherwise they will all work
differently. This is not to say driver writers aren't allowed to depart
from it, just that it'll be more work if they do.
> > /dev/draw is interesting but largely irrelevant. And again, colormap and
> > refresh - why are they not part of ctl? You've got to select on refresh
> > anyway, might as well accept asynchronous messages through ctl.
>
> You've got to do _what_ on refresh?
I'm guessing some sort of poll or select on the refresh device, assuming a
single-threaded app. But no, I've never used 9 nor am I especially
interested in exploring it in depth, given its license and lack of
community.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Alexander Viro wrote:
> On Mon, 21 May 2001, Oliver Xymoron wrote:
>
> > If you've got side channels that are of a packet nature (aka commands),
> > then they can all happily coexist on one device. If you've got channels
> > that are streams or intended for mmap, those ought to be different
> > devices.
>
> Since you've been refering to -9 - care to take a look at the contents of
> uart(3)? Or lpt(3). Or draw(3), for that matter.
K - so what? I'm guessing what you want me to see is that these
implement multiple channels. Is there a reason that eia001stat couldn't be
implemented as
f=open("/dev/eia001ctl",O_RDWR);
write(f,"stat\n");
status=read(f); /* returns "stat foo\n" */
We don't want to implement a separate device node for every OOB ioctl that
returns data, do we? Why should stat be any different?
/dev/draw is interesting but largely irrelevant. And again, colormap and
refresh - why are they not part of ctl? You've got to select on refresh
anyway, might as well accept asynchronous messages through ctl.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Mon, 21 May 2001, David Lang wrote: > what makes you think it's safe to say there's only one floppy drive? Read as: it doesn't make sense to have per-fd state on a single floppy device given that there's only one actual hardware instance associated with it and multiple openers don't make sense. Opening a floppy at different densities with magic filenames was an example Linus used earlier in the thread. Surely there can be more than one drive and more than one serial port. > On Mon, 21 May 2001, Oliver Xymoron wrote: > > > On Sat, 19 May 2001, Alexander Viro wrote: > > > > > Let's distinguish between per-fd effects (that's what name in > > > open(name, flags) is for - you are asking for descriptor and telling > > > what behaviour do you want for IO on it) and system-wide side effects. > > > > > > IMO encoding the former into name is perfectly fine, and no write on > > > another file can be sanely used for that purpose. For the latter, though, > > > we need to write commands into files and here your miscdevices (or procfs > > > files, or /dev/foo/ctl - whatever) is needed. > > > > I'm a little skeptical about the necessity of these per-fd effects in the > > first place - after all, Plan 9 does without them. There's only one > > floppy drive, yes? No concurrent users of serial ports? The counter that > > comes to mind is sound devices supporting multiple opens, but I think > > esound and friends are a better solution to that problem. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, Alexander Viro wrote: > On Sun, 20 May 2001, Abramo Bagnara wrote: > > > > It may have several. Which one? > > > > Can you explain better this? > > Example: console. You want to be able to pass font changes. I'm > less than sure that putting them on the same channel as, e.g., > keyboard mapping changes is a good idea. If you've got side channels that are of a packet nature (aka commands), then they can all happily coexist on one device. If you've got channels that are streams or intended for mmap, those ought to be different devices. > Moreover, we have channels that are not tied to a particular device - > they are for a group of them. Example: setting timings for IDE controller. > Sure, we can just say "open /dev/hda instead of /dev/hda5", but then we > are back to the "find related file" problem you tried to avoid. Hmmm.. I suspect there's a permission issue lurking here anyway. It's probably valid to want to give out raw partition access, say to a database user, but not to give out permission to fiddle with the underlying drive. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Jeff Garzik wrote: > Why are LVM and EVMS(competing LVM project) needed at all? > > Surely the same can be accomplished with > * md > * snapshot blkdev (attached in previous e-mail) > * giving partitions and blkdevs the ability to grow and shrink > * giving filesystems the ability to grow and shrink You can migrate data off disks while the filesystems on top of them are live. Add disk b, migrate a->b, remove disk a. Perhaps this is intrinsic in the above somehow but I don't see it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Alexander Viro wrote: > Let's distinguish between per-fd effects (that's what name in > open(name, flags) is for - you are asking for descriptor and telling > what behaviour do you want for IO on it) and system-wide side effects. > > IMO encoding the former into name is perfectly fine, and no write on > another file can be sanely used for that purpose. For the latter, though, > we need to write commands into files and here your miscdevices (or procfs > files, or /dev/foo/ctl - whatever) is needed. I'm a little skeptical about the necessity of these per-fd effects in the first place - after all, Plan 9 does without them. There's only one floppy drive, yes? No concurrent users of serial ports? The counter that comes to mind is sound devices supporting multiple opens, but I think esound and friends are a better solution to that problem. What I'd like to see: - An interface for registering an array of related devices (almost always two: raw and ctl) and their legacy device numbers with a single userspace callout that does whatever /dev/ creation needs to be done. Thus, naming and permissions live in user space. No "device node is also a directory" weirdness which is overkill in the vast majority of cases. No kernel names or permissions leaking into userspace. - An unregister_devices that does the same, giving userspace a chance to persist permissions, etc. - A userspace program that keeps a mapping of kernel names to /dev/ names, permissions, etc. - An autofs hook that does the reverse mapping for running with modules (possibly calling modprobe directly) Possible future extension: - Allow exporting proc as a large collection of devices. Manage /proc in userspace on a tmpfs. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Sun, 20 May 2001, Alexander Viro wrote: On Sun, 20 May 2001, Abramo Bagnara wrote: It may have several. Which one? Can you explain better this? Example: console. You want to be able to pass font changes. I'm less than sure that putting them on the same channel as, e.g., keyboard mapping changes is a good idea. If you've got side channels that are of a packet nature (aka commands), then they can all happily coexist on one device. If you've got channels that are streams or intended for mmap, those ought to be different devices. Moreover, we have channels that are not tied to a particular device - they are for a group of them. Example: setting timings for IDE controller. Sure, we can just say open /dev/hda instead of /dev/hda5, but then we are back to the find related file problem you tried to avoid. Hmmm.. I suspect there's a permission issue lurking here anyway. It's probably valid to want to give out raw partition access, say to a database user, but not to give out permission to fiddle with the underlying drive. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Alexander Viro wrote: On Mon, 21 May 2001, Oliver Xymoron wrote: If you've got side channels that are of a packet nature (aka commands), then they can all happily coexist on one device. If you've got channels that are streams or intended for mmap, those ought to be different devices. Since you've been refering to -9 - care to take a look at the contents of uart(3)? Or lpt(3). Or draw(3), for that matter. K - so what? I'm guessing what you want me to see is that these implement multiple channels. Is there a reason that eia001stat couldn't be implemented as f=open(/dev/eia001ctl,O_RDWR); write(f,stat\n); status=read(f); /* returns stat foo\n */ We don't want to implement a separate device node for every OOB ioctl that returns data, do we? Why should stat be any different? /dev/draw is interesting but largely irrelevant. And again, colormap and refresh - why are they not part of ctl? You've got to select on refresh anyway, might as well accept asynchronous messages through ctl. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNum
On Mon, 21 May 2001, Alexander Viro wrote: On Mon, 21 May 2001, Oliver Xymoron wrote: K - so what? I'm guessing what you want me to see is that these implement multiple channels. Is there a reason that eia001stat couldn't be implemented as f=open(/dev/eia001ctl,O_RDWR); write(f,stat\n); status=read(f); /* returns stat foo\n */ Less convenient. True enough. We don't want to implement a separate device node for every OOB ioctl that returns data, do we? Why should stat be any different? For every? Probably not. Forcing all of them together? I bet that in many cases it will be damn inconvenient. You are forcing the policy on all drivers. For no good reason, AFAICS. No - I'm merely pointing out that it's sufficient. And I'm pretty sure we want to make additional control or stream interfaces the exception rather than the rule. And having a standard read and write protocol of some sort for ctl devices is more or less mandatory, otherwise they will all work differently. This is not to say driver writers aren't allowed to depart from it, just that it'll be more work if they do. /dev/draw is interesting but largely irrelevant. And again, colormap and refresh - why are they not part of ctl? You've got to select on refresh anyway, might as well accept asynchronous messages through ctl. You've got to do _what_ on refresh? I'm guessing some sort of poll or select on the refresh device, assuming a single-threaded app. But no, I've never used 9 nor am I especially interested in exploring it in depth, given its license and lack of community. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Mon, 21 May 2001, David Lang wrote: what makes you think it's safe to say there's only one floppy drive? Read as: it doesn't make sense to have per-fd state on a single floppy device given that there's only one actual hardware instance associated with it and multiple openers don't make sense. Opening a floppy at different densities with magic filenames was an example Linus used earlier in the thread. Surely there can be more than one drive and more than one serial port. On Mon, 21 May 2001, Oliver Xymoron wrote: On Sat, 19 May 2001, Alexander Viro wrote: Let's distinguish between per-fd effects (that's what name in open(name, flags) is for - you are asking for descriptor and telling what behaviour do you want for IO on it) and system-wide side effects. IMO encoding the former into name is perfectly fine, and no write on another file can be sanely used for that purpose. For the latter, though, we need to write commands into files and here your miscdevices (or procfs files, or /dev/foo/ctl - whatever) is needed. I'm a little skeptical about the necessity of these per-fd effects in the first place - after all, Plan 9 does without them. There's only one floppy drive, yes? No concurrent users of serial ports? The counter that comes to mind is sound devices supporting multiple opens, but I think esound and friends are a better solution to that problem. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Jeff Garzik wrote: Why are LVM and EVMS(competing LVM project) needed at all? Surely the same can be accomplished with * md * snapshot blkdev (attached in previous e-mail) * giving partitions and blkdevs the ability to grow and shrink * giving filesystems the ability to grow and shrink You can migrate data off disks while the filesystems on top of them are live. Add disk b, migrate a-b, remove disk a. Perhaps this is intrinsic in the above somehow but I don't see it. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Sat, 19 May 2001, Alexander Viro wrote: Let's distinguish between per-fd effects (that's what name in open(name, flags) is for - you are asking for descriptor and telling what behaviour do you want for IO on it) and system-wide side effects. IMO encoding the former into name is perfectly fine, and no write on another file can be sanely used for that purpose. For the latter, though, we need to write commands into files and here your miscdevices (or procfs files, or /dev/foo/ctl - whatever) is needed. I'm a little skeptical about the necessity of these per-fd effects in the first place - after all, Plan 9 does without them. There's only one floppy drive, yes? No concurrent users of serial ports? The counter that comes to mind is sound devices supporting multiple opens, but I think esound and friends are a better solution to that problem. What I'd like to see: - An interface for registering an array of related devices (almost always two: raw and ctl) and their legacy device numbers with a single userspace callout that does whatever /dev/ creation needs to be done. Thus, naming and permissions live in user space. No device node is also a directory weirdness which is overkill in the vast majority of cases. No kernel names or permissions leaking into userspace. - An unregister_devices that does the same, giving userspace a chance to persist permissions, etc. - A userspace program that keeps a mapping of kernel names to /dev/ names, permissions, etc. - An autofs hook that does the reverse mapping for running with modules (possibly calling modprobe directly) Possible future extension: - Allow exporting proc as a large collection of devices. Manage /proc in userspace on a tmpfs. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Alternatives to device nodes as directories idea?
It seems to me that Linus' idea of making device nodes work like
directories is a little too clever and probably overkill but the only
alternative I've seen suggested is Al's per-device filesystems which seems
similarly excessive.
Few devices will have a need for multiple streamable interfaces and should
probably be fine with one acting as the 'normal' device and another acting
as a control device replacing ioctl. This would leave most of these weird
directory-like objects containing only one file. And then there's the
issue that the naming and permissions of that file ends up being a matter
of kernel policy.
As an alternative, I suggest something like:
struct devicetype
{
char name[16];
struct list_head isa; /* base types */
};
struct devicereg
{
kdev_t dev; /* kdev_t could also include the following */
char name[16]; /* symbolic in-kernel name for this device */
struct devicetype devtype;
int block; /* block or char */
dev_t major, minor; /* legacy numbers, deprecated */
};
int register_devices(const devicereg *d, int n);
Register_devices then makes a single call to a userspace helper,
passing it a list of symbolic names and major/minor numbers associated
with a detected device. This lets the helper configure them as a
group. It can even mount per-device tmpfs directories to look like
Al's world.
Still missing is a scheme to allow the kernel to rendezvous with
userspace when a user wants to open a device that's a module and has
therefore not been detected yet. Presumably the userspace helper
mentioned above keeps a mapping of kernel name->userspace name, so
using the inverse of this map with autofs should allow module
probing-like behavior.
This still leaves cases that don't work: booting off IDE, SCSI built
as a module, trying to mount a SCSI disk by UUID... But that doesn't
work now.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alternatives to device nodes as directories idea?
It seems to me that Linus' idea of making device nodes work like
directories is a little too clever and probably overkill but the only
alternative I've seen suggested is Al's per-device filesystems which seems
similarly excessive.
Few devices will have a need for multiple streamable interfaces and should
probably be fine with one acting as the 'normal' device and another acting
as a control device replacing ioctl. This would leave most of these weird
directory-like objects containing only one file. And then there's the
issue that the naming and permissions of that file ends up being a matter
of kernel policy.
As an alternative, I suggest something like:
struct devicetype
{
char name[16];
struct list_head isa; /* base types */
};
struct devicereg
{
kdev_t dev; /* kdev_t could also include the following */
char name[16]; /* symbolic in-kernel name for this device */
struct devicetype devtype;
int block; /* block or char */
dev_t major, minor; /* legacy numbers, deprecated */
};
int register_devices(const devicereg *d, int n);
Register_devices then makes a single call to a userspace helper,
passing it a list of symbolic names and major/minor numbers associated
with a detected device. This lets the helper configure them as a
group. It can even mount per-device tmpfs directories to look like
Al's world.
Still missing is a scheme to allow the kernel to rendezvous with
userspace when a user wants to open a device that's a module and has
therefore not been detected yet. Presumably the userspace helper
mentioned above keeps a mapping of kernel name-userspace name, so
using the inverse of this map with autofs should allow module
probing-like behavior.
This still leaves cases that don't work: booting off IDE, SCSI built
as a module, trying to mount a SCSI disk by UUID... But that doesn't
work now.
--
Love the dolphins, she advised him. Write by W.A.S.T.E..
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: comments on CML 1.1.0
On Sat, 14 Apr 2001, Eric S. Raymond wrote: > > * the colors are hard to see (red/blue on black). Probably > > matter of terminal settings. I do not have any productive > > ideas tho... Probably to get best experience to as much > > people as possible the less colors are used the better. > > > > The 'blue: last visited submenu' is unnecessary. Especially > > because it later turns green... And the 'red' vs. 'green' > > thing. I guess the green should be used for 'visited entries' > > too. Now the red means like 'Doh. So I should not have > > touched this?'. Confusing. > > > > In other words: if there are too much colors, they become > > a thing that should be separately learned, not a helpful > > aid. > > > > All this IMHO ofcourse. Colors are 'matter of taste' thing > > so there probably is not exact Rigth Thing. > > You make good points. In the 1.1.1, blue and yellow/brown will be gone; > it's just green for everything visited. I haven't had a chance to take a look, but a heads-up about color confusion issues. There may be no right thing, but there are plenty of wrong things. For instance, for about 4% of people (8% of males), RGB 00 and 00FF00 are nearly indistiguishable, as are FF00FF and FF. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: comments on CML 1.1.0
On Sat, 14 Apr 2001, Eric S. Raymond wrote: * the colors are hard to see (red/blue on black). Probably matter of terminal settings. I do not have any productive ideas tho... Probably to get best experience to as much people as possible the less colors are used the better. The 'blue: last visited submenu' is unnecessary. Especially because it later turns green... And the 'red' vs. 'green' thing. I guess the green should be used for 'visited entries' too. Now the red means like 'Doh. So I should not have touched this?'. Confusing. In other words: if there are too much colors, they become a thing that should be separately learned, not a helpful aid. All this IMHO ofcourse. Colors are 'matter of taste' thing so there probably is not exact Rigth Thing. You make good points. In the 1.1.1, blue and yellow/brown will be gone; it's just green for everything visited. I haven't had a chance to take a look, but a heads-up about color confusion issues. There may be no right thing, but there are plenty of wrong things. For instance, for about 4% of people (8% of males), RGB 00 and 00FF00 are nearly indistiguishable, as are FF00FF and FF. -- Love the dolphins, she advised him. Write by W.A.S.T.E.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, 9 Apr 2001, Alan Cox wrote: > > > Its worth doing even on the ancient x86 boards with the PIT. > > > > Note that programming the PIT is slw and doing it on every timer > > add_timer/del_timer would be a pain. > > You only have to do it occasionally. > > When you add a timer newer than the current one > (arguably newer by at least 1/2*HZ sec) That's only if we want to do no better than the current system. We'd want a new variable called timer_margin or something, which would be dependent on interrupt source and processor, and could be tuned up or down via sysctl. > When you finish running the timers at an interval and the new interval is > significantly larger than the current one. Make that larger or smaller. If we come out of a quiescent state (1 hz interrupts, say) and start getting 10ms timers, we want to respond to them right away. > Remember each tick we poke the PIT anyway We could also have a HZ_max tunable above which we would not try to reprogram the interval. On older systems, this could be set at 100-200HZ... -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, 9 Apr 2001, Alan Cox wrote: Its worth doing even on the ancient x86 boards with the PIT. Note that programming the PIT is slw and doing it on every timer add_timer/del_timer would be a pain. You only have to do it occasionally. When you add a timer newer than the current one (arguably newer by at least 1/2*HZ sec) That's only if we want to do no better than the current system. We'd want a new variable called timer_margin or something, which would be dependent on interrupt source and processor, and could be tuned up or down via sysctl. When you finish running the timers at an interval and the new interval is significantly larger than the current one. Make that larger or smaller. If we come out of a quiescent state (1 hz interrupts, say) and start getting 10ms timers, we want to respond to them right away. Remember each tick we poke the PIT anyway We could also have a HZ_max tunable above which we would not try to reprogram the interval. On older systems, this could be set at 100-200HZ... -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Jeff Garzik wrote: > Oliver Xymoron wrote: > > On Mon, 2 Apr 2001, Tom Leete wrote: > > > How about /lib/modules/$(uname -r)/build/.config ? It's already there. > > > It'd be great if we got away from the config being hidden too. > > When exporting it outside the kernel tree, the '.' prefix should > definitely be stripped... I think the same should be true for the new build system as well. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Tom Leete wrote: > Oliver Xymoron wrote: > > > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > > > On Sun, 1 Apr 2001, David Lang wrote: > > > > if we want to get the .config as part of the report then we need to make > > > > it part of the kernel in some standard way (the old /proc/config flamewar) > > > > it's difficult enough sometimes for the sysadmin of a box to know what > > > > kernel is running on it, let alone a bug reporting script. > > > > > > Let's hope it's not a flamewar, but here goes :) > > > > > > We -need- .config, but /proc/config seems like pure bloat. > > > > As a former proponent of /proc/config (I wrote one of the much-debated > > patches), I tend to agree. Debian's make-kpkg does the right thing, namely > > treating .config the same way it treats System-map, putting it in the > > package and eventually installing it in /boot/config-x.y.z. If Redhat's > > kernel-install script did the same it would rapidly become a non-issue. > > How about /lib/modules/$(uname -r)/build/.config ? It's already there. It'd be great if we got away from the config being hidden too. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Jeff Garzik wrote: > On Sun, 1 Apr 2001, David Lang wrote: > > if we want to get the .config as part of the report then we need to make > > it part of the kernel in some standard way (the old /proc/config flamewar) > > it's difficult enough sometimes for the sysadmin of a box to know what > > kernel is running on it, let alone a bug reporting script. > > Let's hope it's not a flamewar, but here goes :) > > We -need- .config, but /proc/config seems like pure bloat. As a former proponent of /proc/config (I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in /boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old /proc/config flamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems like pure bloat. As a former proponent of /proc/config (I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in /boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Tom Leete wrote: Oliver Xymoron wrote: On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old /proc/config flamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems like pure bloat. As a former proponent of /proc/config (I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in /boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue. How about /lib/modules/$(uname -r)/build/.config ? It's already there. It'd be great if we got away from the config being hidden too. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug database braindump from the kernel summit
On Mon, 2 Apr 2001, Jeff Garzik wrote: Oliver Xymoron wrote: On Mon, 2 Apr 2001, Tom Leete wrote: How about /lib/modules/$(uname -r)/build/.config ? It's already there. It'd be great if we got away from the config being hidden too. When exporting it outside the kernel tree, the '.' prefix should definitely be stripped... I think the same should be true for the new build system as well. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Rename all derived CONFIG variables
On Mon, 12 Mar 2001, Keith Owens wrote: > On Mon, 12 Mar 2001 03:53:07 -0500, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >But if we're going to push Linus and the kernel crew to switch to > >CML2, then why invite the political tsuris of trying to get a large > >patch into 2.4 now? Maybe I'm missing something here, but this doesn't > >seem necessary to me. > > The derived config variables should be in a separate name space, > whether config is CML1 or CML2. This patch does it for CML1. I don't think this makes sense at all. The derivation of the config values is the concern of the configuration system, not the code. Consider something like CONFIG_CPU_HAS_FEATURE_FOO that might currently be derived from CONFIG_CPU_BAR but may in the future be made independent. Or vice-versa. Your proposed name-change means additional maintenance headache and gets you nothing that you couldn't get by simply including whatever script you wrote to deduce the dependencies. Such a script would at least be able to tell you what a variable was derived from. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Rename all derived CONFIG variables
On Mon, 12 Mar 2001, Keith Owens wrote: On Mon, 12 Mar 2001 03:53:07 -0500, "Eric S. Raymond" [EMAIL PROTECTED] wrote: But if we're going to push Linus and the kernel crew to switch to CML2, then why invite the political tsuris of trying to get a large patch into 2.4 now? Maybe I'm missing something here, but this doesn't seem necessary to me. The derived config variables should be in a separate name space, whether config is CML1 or CML2. This patch does it for CML1. I don't think this makes sense at all. The derivation of the config values is the concern of the configuration system, not the code. Consider something like CONFIG_CPU_HAS_FEATURE_FOO that might currently be derived from CONFIG_CPU_BAR but may in the future be made independent. Or vice-versa. Your proposed name-change means additional maintenance headache and gets you nothing that you couldn't get by simply including whatever script you wrote to deduce the dependencies. Such a script would at least be able to tell you what a variable was derived from. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, 9 Mar 2001, Rogier Wolff wrote: > Quicksort however is an algorithm that is recursive. This means that > it can use unbounded amounts of stack -> This is not for the kernel. It is of course bounded by the input size, but yes, it can use O(n) additional memory in the worst case. There's no particular reason this memory has to be on the stack - it's just convenient. > Isn't it easier to do "insertion sort": Keep the lists sorted, and > insert the item at the right place when you get the new item. Assuming you get your items in sorted order, this is also O(N^2). -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, 9 Mar 2001, Alan Cox wrote: > > Quicksort works just fine on a linked list, as long as you broaden > > your view beyond the common array-based implementations. See > > "http://www.cs.cmu.edu/~jbruce/sort.cc" for an example, although I > > would recommend using a radix sort for linked lists in most situations > > (sorry for the C++, but it was handy...). > > In a network environment however its not so good. Quicksort has an N^2 > worst case and the input is controlled by a potential enemy. It's not too hard to patch that up, eg quickersort. N^2 isn't too bad for short queues anyway especially considering the complexity of the alternatives. > Im dubious about anyone doing more than simple bucket sorting for packets. Assume you mean sorting into hash buckets as opposed to "count the number of occurrences of each type of element in a narrow range, discarding the actual element". Most hashes are subvertible too and probably don't fair any better than N^2. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, 9 Mar 2001, Helge Hafting wrote:
> Manoj Sontakke wrote:
> >
> > 1. Is quicksort on doubly linked list is implemented anywhere? I need it
> > for sk_buff queues.
>
> I cannot see how the quicksort algorithm could work on a doubly
> linked list, as it relies on being able to look
> up elements directly as in an array.
>
> You can probably find algorithms for sorting a linked list, but
> it won't be quicksort.
Here ya go (wrote this a few years ago):
// This function is so cool.
template
void list::qsort(iter l, iter r, cmpfunc *cmp, void *data)
{
if(l==r) return;
iter i(l), p(l);
for(i++; i!=r; i++)
if(cmp(*i, *l, data)<0)
i.swap(++p);
l.swap(p);
qsort(l, p, cmp, data);
qsort(++p, r, cmp, data);
}
Iters are essentially list pointers with increment operations. This is a
fairly direct adaptation of the quicksort in K, actually.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, 9 Mar 2001, Helge Hafting wrote:
Manoj Sontakke wrote:
1. Is quicksort on doubly linked list is implemented anywhere? I need it
for sk_buff queues.
I cannot see how the quicksort algorithm could work on a doubly
linked list, as it relies on being able to look
up elements directly as in an array.
You can probably find algorithms for sorting a linked list, but
it won't be quicksort.
Here ya go (wrote this a few years ago):
// This function is so cool.
templateclass T
void listT::qsort(iter l, iter r, cmpfunc *cmp, void *data)
{
if(l==r) return;
iter i(l), p(l);
for(i++; i!=r; i++)
if(cmp(*i, *l, data)0)
i.swap(++p);
l.swap(p);
qsort(l, p, cmp, data);
qsort(++p, r, cmp, data);
}
Iters are essentially list pointers with increment operations. This is a
fairly direct adaptation of the quicksort in KR, actually.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, 9 Mar 2001, Alan Cox wrote: Quicksort works just fine on a linked list, as long as you broaden your view beyond the common array-based implementations. See "http://www.cs.cmu.edu/~jbruce/sort.cc" for an example, although I would recommend using a radix sort for linked lists in most situations (sorry for the C++, but it was handy...). In a network environment however its not so good. Quicksort has an N^2 worst case and the input is controlled by a potential enemy. It's not too hard to patch that up, eg quickersort. N^2 isn't too bad for short queues anyway especially considering the complexity of the alternatives. Im dubious about anyone doing more than simple bucket sorting for packets. Assume you mean sorting into hash buckets as opposed to "count the number of occurrences of each type of element in a narrow range, discarding the actual element". Most hashes are subvertible too and probably don't fair any better than N^2. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
On Fri, 9 Mar 2001, Rogier Wolff wrote: Quicksort however is an algorithm that is recursive. This means that it can use unbounded amounts of stack - This is not for the kernel. It is of course bounded by the input size, but yes, it can use O(n) additional memory in the worst case. There's no particular reason this memory has to be on the stack - it's just convenient. Isn't it easier to do "insertion sort": Keep the lists sorted, and insert the item at the right place when you get the new item. Assuming you get your items in sorted order, this is also O(N^2). -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Penguin logos
On Thu, 8 Mar 2001, Geert Uytterhoeven wrote: > Patches (for both 2.4.3-pre3 and 2.4.2-ac14) can be downloaded from: > > http://home.tvd.be/cr26864/Linux/fbdev/logo.html > > This page also shows the old and new logos, and includes a tool to extract > logos in PNM format from the kernel sources (in case you don't trust me :-). There's still some aliasing outlines on a bunch of them and I'm a bit puzzled why there's an SGI logo on the MIPS penguin but not on the SGI penguin. Ideally, it'd be preferable to have .pnms in the source and a quick prog in tools/ to build the include files as part of the makefile. Source should be editable. While I'm at it, may I suggest trading the gray background for black with the penguin surrounded by a halo effect? It enhances his already, erm, Buddha-esque appearance, to say nothing of "holy penguin pee". -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." holypenguin.png
Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened ?(No
On Wed, 7 Mar 2001, Ben Greear wrote: > For the power/insane user, there could be a --really-do-stupid-thing-i-told-you-to > option, and it should be that hard to type!! There is, though historically it's undocumented. It's called "root password". Pause. Reflect. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] documentation for mm.h
On Wed, 7 Mar 2001, Rik van Riel wrote: > I've taken today to write some documentation for > include/linux/mm.h, as used in 2.4.x Mostly good. > + pgprot_t vm_page_prot; /* Access permissions of this VMA. */ But a lot of the comments are trivial = deadweight. Comments are best used for the bits that are magical without them, which should be few. > + struct page *next_hash; /* Next page sharing our hash bucket in > +the pagecache hash table. */ Multiline comments at the end of the line are hard to maintain and highly susceptible to tab damage. > + atomic_t count; /* Usage count, see below. */ > + unsigned long flags;/* atomic flags, some possibly > +updated asynchronously */ I'm sure there's a good reason why the flags aren't atomic_t but this comment would make me suspect a bug. Comments that don't agree with code are worse than no comments. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] documentation for mm.h
On Wed, 7 Mar 2001, Rik van Riel wrote: I've taken today to write some documentation for include/linux/mm.h, as used in 2.4.x Mostly good. + pgprot_t vm_page_prot; /* Access permissions of this VMA. */ But a lot of the comments are trivial = deadweight. Comments are best used for the bits that are magical without them, which should be few. + struct page *next_hash; /* Next page sharing our hash bucket in +the pagecache hash table. */ Multiline comments at the end of the line are hard to maintain and highly susceptible to tab damage. + atomic_t count; /* Usage count, see below. */ + unsigned long flags;/* atomic flags, some possibly +updated asynchronously */ I'm sure there's a good reason why the flags aren't atomic_t but this comment would make me suspect a bug. Comments that don't agree with code are worse than no comments. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Penguin logos
On Thu, 8 Mar 2001, Geert Uytterhoeven wrote: Patches (for both 2.4.3-pre3 and 2.4.2-ac14) can be downloaded from: http://home.tvd.be/cr26864/Linux/fbdev/logo.html This page also shows the old and new logos, and includes a tool to extract logos in PNM format from the kernel sources (in case you don't trust me :-). There's still some aliasing outlines on a bunch of them and I'm a bit puzzled why there's an SGI logo on the MIPS penguin but not on the SGI penguin. Ideally, it'd be preferable to have .pnms in the source and a quick prog in tools/ to build the include files as part of the makefile. Source should be editable. While I'm at it, may I suggest trading the gray background for black with the penguin surrounded by a halo effect? It enhances his already, erm, Buddha-esque appearance, to say nothing of "holy penguin pee". -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." holypenguin.png
Re: The IO problem on multiple PCI busses
On Fri, 2 Mar 2001, David S. Miller wrote:
> > On PPC, we don't have an "IO" space neither, all we have is a range of
> > memory addresses that will cause IO cycles to happen on the PCI bus.
>
> This is precisely what the "next MMAP is XXX space" ioctl I've
> suggested is for. I think I've addressed this concern in my
> proposal already. Look:
>
> fd = open("/proc/bus/pci/${BUS}/${DEV}", ...);
> if (fd < 0)
> return -errno;
> err = ioctl(fd, PCI_MMAP_IO, 0);
I know I'm coming in on this late, but wouldn't it be cleaner to have
separate files for memory and io cycles, eg ${BUS}/${DEV}.(io|mem)?
They're logically different so they might as well be embodied separately.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
On Fri, 2 Mar 2001, David S. Miller wrote:
On PPC, we don't have an "IO" space neither, all we have is a range of
memory addresses that will cause IO cycles to happen on the PCI bus.
This is precisely what the "next MMAP is XXX space" ioctl I've
suggested is for. I think I've addressed this concern in my
proposal already. Look:
fd = open("/proc/bus/pci/${BUS}/${DEV}", ...);
if (fd 0)
return -errno;
err = ioctl(fd, PCI_MMAP_IO, 0);
I know I'm coming in on this late, but wouldn't it be cleaner to have
separate files for memory and io cycles, eg ${BUS}/${DEV}.(io|mem)?
They're logically different so they might as well be embodied separately.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] big udelay's in fb drivers (2.4.0-prerelease)
On Fri, 5 Jan 2001, Alan Cox wrote: > > Once the comments are unweirded, they become completely superfluous. At > > which point its best not to have them - when someone next comes along and > > changes the delay, it might end up disagreeing with the comment and > > causing confusion. > > Before you remove the comments check with the author and the manuals. Huh? Granted that's generally a good idea, but if you've got code that says udelay(15000); /* delay 15ms */ the comment is just extra baggage. No sense touching it generally, but if you're gonna change it to mdelay.. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] big udelay's in fb drivers (2.4.0-prerelease)
On Thu, 4 Jan 2001, Marko Kreen wrote: > On Wed, Jan 03, 2001 at 11:32:52PM +0200, Marko Kreen wrote: > > -udelay(15000); /* delay for 50 (15) ms */ > > +mdelay(15); /* delay for 50 (15) ms */ > > Per Mark Hahn suggestion here is a patch that fixes the weird > comments too. This is cumulative to the previous patch. Once the comments are unweirded, they become completely superfluous. At which point its best not to have them - when someone next comes along and changes the delay, it might end up disagreeing with the comment and causing confusion. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
On Thu, 4 Jan 2001, Alexander Viro wrote: > > I bet it long predates dcache though.. > > Not too likely. It went in in 2.1.93. Apr 2 1998... > Dcache was there ~50 versions before that. Huh. Is there anything that prevents fragmentation in, say, growing maildirs, where there's nothing but locality to hold the directory inode in cache? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove more compile warnings in 2.4.0-prerelease
On Tue, 2 Jan 2001, Rich Baum wrote: > Here is a patch that removes more compile warnings from 2.4.0- > prerelease. I left out files that have been fixed by Alan or myself in > the ac kernels. I'll add more options to my config tomorrow to try to > find more of these warnings. > -#endif I2C_PCF8584_H > +#endif /* I2C_PCF8584_H */ [etc.] Here, try this: find -name "*.[ch]" | xargs perl -ne 'print "$ARGV:$_" if /#endif\s+\w/i' You'll find a few hundred of them. Then try this (untested): find -name "*.[ch]" | xargs perl -i -pe 's/#endif\s+(\w.*)/#endif \/\* $1 \/\*/i' ..and save yourself quite a bit of tedium. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
On Wed, 3 Jan 2001, Alexander Viro wrote: > On Wed, 3 Jan 2001, Stephen C. Tweedie wrote: > > > Having preallocated blocks allocated immediately is deliberate: > > directories grow slowly and remain closed most of the time, so the > > normal preallocation regime of only preallocating open files and > > discarding preallocation on close just doesn't work. > > Erm. For directories we would not have the call of discard_prealloc() > on close(2) - they have NULL ->release() anyway and for them it would > happen only on ext2_put_inode(), i.e. upon the final dput(). Which would > not happen while some descendent would stay in dcache. I bet it long predates dcache though.. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
On Wed, 3 Jan 2001, Alexander Viro wrote: On Wed, 3 Jan 2001, Stephen C. Tweedie wrote: Having preallocated blocks allocated immediately is deliberate: directories grow slowly and remain closed most of the time, so the normal preallocation regime of only preallocating open files and discarding preallocation on close just doesn't work. Erm. For directories we would not have the call of discard_prealloc() on close(2) - they have NULL -release() anyway and for them it would happen only on ext2_put_inode(), i.e. upon the final dput(). Which would not happen while some descendent would stay in dcache. I bet it long predates dcache though.. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove more compile warnings in 2.4.0-prerelease
On Tue, 2 Jan 2001, Rich Baum wrote: Here is a patch that removes more compile warnings from 2.4.0- prerelease. I left out files that have been fixed by Alan or myself in the ac kernels. I'll add more options to my config tomorrow to try to find more of these warnings. -#endif I2C_PCF8584_H +#endif /* I2C_PCF8584_H */ [etc.] Here, try this: find -name "*.[ch]" | xargs perl -ne 'print "$ARGV:$_" if /#endif\s+\w/i' You'll find a few hundred of them. Then try this (untested): find -name "*.[ch]" | xargs perl -i -pe 's/#endif\s+(\w.*)/#endif \/\* $1 \/\*/i' ..and save yourself quite a bit of tedium. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
On Thu, 4 Jan 2001, Alexander Viro wrote: I bet it long predates dcache though.. Not too likely. checking CVS It went in in 2.1.93. Apr 2 1998... Dcache was there ~50 versions before that. Huh. Is there anything that prevents fragmentation in, say, growing maildirs, where there's nothing but locality to hold the directory inode in cache? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Mobile PII vs PIII was Re: test13-pre[37] hangs my VAIO on boot
On Sun, 31 Dec 2000, Oliver Xymoron wrote: > My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling > required to reboot. Unpatched test12 works fine with same config. System > is debian-testing with gcc 2.95.2, kernel built with make-kpkg. Ok, I lied. Looks like the working test12 I had was compiled differently. > CONFIG_M686FXSR=y ... > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_L1_CACHE_SHIFT=5 > CONFIG_X86_TSC=y > CONFIG_X86_GOOD_APIC=y > CONFIG_X86_PGE=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_FXSR=y > CONFIG_X86_XMM=y My VAIO has a Mobile Pentium II. Which means it is indeed a 686 with FXSR, but no XMM. There are of course locking primitives that change with the presence of CONFIG_X86_XMM. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patchlet] enable HP 8200e USB CDRW
On Sun, 31 Dec 2000, Matthew Dharm wrote: > Um, I'm not sure that this driver is even ready for the EXPERIMENTAL label. > What does the driver's author say? He was unresponsive to my message of about a month ago. Nonetheless, it works for me - I've ripped about a hundred CDs and burned a few as well. Considering that the rest of the code is already in the standard kernel and appears to work, there's no reason not to make it available. > On Sun, Dec 31, 2000 at 11:50:14AM -0600, Oliver Xymoron wrote: > > This patchlet lets me use my HP CDRW. > > > > --- linux/drivers/usb/Config.in~Mon Nov 27 20:10:35 2000 > > +++ linux/drivers/usb/Config.in Tue Dec 19 12:21:56 2000 > > @@ -32,6 +32,9 @@ > > if [ "$CONFIG_USB_STORAGE" != "n" ]; then > >bool 'USB Mass Storage verbose debug' CONFIG_USB_STORAGE_DEBUG > >bool 'Freecom USB/ATAPI Bridge support' CONFIG_USB_STORAGE_FREECOM > > + if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then > > + bool 'HP8200e support (EXPERIMENTAL)' CONFIG_USB_STORAGE_HP8200e > > + fi > > fi > > dep_tristate ' USB Modem (CDC ACM) support' CONFIG_USB_ACM $CONFIG_USB > > dep_tristate ' USB Printer support' CONFIG_USB_PRINTER $CONFIG_USB -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test13-pre[37] hangs my VAIO on boot
My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling required to reboot. Unpatched test12 works fine with same config. System is debian-testing with gcc 2.95.2, kernel built with make-kpkg. BTW, my USB camera (Canon S100), controlled through usbdevfs with gphoto2, stopped working with test12. # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MTRR is not set CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set # CONFIG_TCIC is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y
[patchlet] enable HP 8200e USB CDRW
This patchlet lets me use my HP CDRW. --- linux/drivers/usb/Config.in~Mon Nov 27 20:10:35 2000 +++ linux/drivers/usb/Config.in Tue Dec 19 12:21:56 2000 @@ -32,6 +32,9 @@ if [ "$CONFIG_USB_STORAGE" != "n" ]; then bool 'USB Mass Storage verbose debug' CONFIG_USB_STORAGE_DEBUG bool 'Freecom USB/ATAPI Bridge support' CONFIG_USB_STORAGE_FREECOM + if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then + bool 'HP8200e support (EXPERIMENTAL)' CONFIG_USB_STORAGE_HP8200e + fi fi dep_tristate ' USB Modem (CDC ACM) support' CONFIG_USB_ACM $CONFIG_USB dep_tristate ' USB Printer support' CONFIG_USB_PRINTER $CONFIG_USB -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patchlet] enable HP 8200e USB CDRW
This patchlet lets me use my HP CDRW. --- linux/drivers/usb/Config.in~Mon Nov 27 20:10:35 2000 +++ linux/drivers/usb/Config.in Tue Dec 19 12:21:56 2000 @@ -32,6 +32,9 @@ if [ "$CONFIG_USB_STORAGE" != "n" ]; then bool 'USB Mass Storage verbose debug' CONFIG_USB_STORAGE_DEBUG bool 'Freecom USB/ATAPI Bridge support' CONFIG_USB_STORAGE_FREECOM + if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then + bool 'HP8200e support (EXPERIMENTAL)' CONFIG_USB_STORAGE_HP8200e + fi fi dep_tristate ' USB Modem (CDC ACM) support' CONFIG_USB_ACM $CONFIG_USB dep_tristate ' USB Printer support' CONFIG_USB_PRINTER $CONFIG_USB -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test13-pre[37] hangs my VAIO on boot
My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling required to reboot. Unpatched test12 works fine with same config. System is debian-testing with gcc 2.95.2, kernel built with make-kpkg. BTW, my USB camera (Canon S100), controlled through usbdevfs with gphoto2, stopped working with test12. # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_M686FXSR=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MTRR is not set CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set # CONFIG_TCIC is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # CONFIG_LVM_PROC_FS is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y
Re: [patchlet] enable HP 8200e USB CDRW
On Sun, 31 Dec 2000, Matthew Dharm wrote: Um, I'm not sure that this driver is even ready for the EXPERIMENTAL label. What does the driver's author say? He was unresponsive to my message of about a month ago. Nonetheless, it works for me - I've ripped about a hundred CDs and burned a few as well. Considering that the rest of the code is already in the standard kernel and appears to work, there's no reason not to make it available. On Sun, Dec 31, 2000 at 11:50:14AM -0600, Oliver Xymoron wrote: This patchlet lets me use my HP CDRW. --- linux/drivers/usb/Config.in~Mon Nov 27 20:10:35 2000 +++ linux/drivers/usb/Config.in Tue Dec 19 12:21:56 2000 @@ -32,6 +32,9 @@ if [ "$CONFIG_USB_STORAGE" != "n" ]; then bool 'USB Mass Storage verbose debug' CONFIG_USB_STORAGE_DEBUG bool 'Freecom USB/ATAPI Bridge support' CONFIG_USB_STORAGE_FREECOM + if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then + bool 'HP8200e support (EXPERIMENTAL)' CONFIG_USB_STORAGE_HP8200e + fi fi dep_tristate ' USB Modem (CDC ACM) support' CONFIG_USB_ACM $CONFIG_USB dep_tristate ' USB Printer support' CONFIG_USB_PRINTER $CONFIG_USB -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Mobile PII vs PIII was Re: test13-pre[37] hangs my VAIO on boot
On Sun, 31 Dec 2000, Oliver Xymoron wrote: My VAIO PCG-Z505SX locks up at "Uncompressing kernel", power cycling required to reboot. Unpatched test12 works fine with same config. System is debian-testing with gcc 2.95.2, kernel built with make-kpkg. Ok, I lied. Looks like the working test12 I had was compiled differently. CONFIG_M686FXSR=y ... CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_FXSR=y CONFIG_X86_XMM=y My VAIO has a Mobile Pentium II. Which means it is indeed a 686 with FXSR, but no XMM. There are of course locking primitives that change with the presence of CONFIG_X86_XMM. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: set_rtc_mmss: can't update from 0 to 59
On Tue, 19 Dec 2000, Russell King wrote: > Oliver Xymoron writes: > > On Mon, 18 Dec 2000, Russell King wrote: > > > So, why don't we update the hours and be done with it? We would have to > > > play the same game with the days of the month vs hours. Also, we don't > > > know if the CMOS clock is programmed for UTC time or not (the kernel's > > > idea of time is UTC. Your CMOS may be programmed for EST for instance). > > > > Sounds like its still broken then - there are time zones which are not > > even multiples of 60 minutes. > > Correct; please examine the code and you will find the answer to this. > Specifically, look at the lines around the following comment: > > /* correct for half hour time zone */ Uhh.. Kathmandu? Chatham Island? +5:45 and +13:45 (DST) respectively. At any rate, the printk should go - do_timer_interrupt already expects the "bug" its reporting. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: set_rtc_mmss: can't update from 0 to 59
On Mon, 18 Dec 2000, Russell King wrote: > Matthew Dharm writes: > > Ahh... I think I see. While the math says "if the diference between the > > real time and the cmos time is less than 30 min", it doesn't recognize that > > the time difference between 2:59 and 3:00 is only 1 min. > > Which is intentional. > > > True enough... but, the question is, how do we fix this? > > Why do you think it needs fixing? > > Think about what happens when the current time according to the CMOS is > 2:59:00 and Linux thinks its 3:01:20. We only write the minutes and > seconds, so if we did write, the CMOS clock then becomes 2:01:20. > Oops, we just lost an hour. Next time you reboot, you'll find the > time out by an hour or more depending on how many corrections of this > type have been done. > > So, why don't we update the hours and be done with it? We would have to > play the same game with the days of the month vs hours. Also, we don't > know if the CMOS clock is programmed for UTC time or not (the kernel's > idea of time is UTC. Your CMOS may be programmed for EST for instance). Sounds like its still broken then - there are time zones which are not even multiples of 60 minutes. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: set_rtc_mmss: can't update from 0 to 59
On Mon, 18 Dec 2000, Russell King wrote: Matthew Dharm writes: Ahh... I think I see. While the math says "if the diference between the real time and the cmos time is less than 30 min", it doesn't recognize that the time difference between 2:59 and 3:00 is only 1 min. Which is intentional. True enough... but, the question is, how do we fix this? Why do you think it needs fixing? Think about what happens when the current time according to the CMOS is 2:59:00 and Linux thinks its 3:01:20. We only write the minutes and seconds, so if we did write, the CMOS clock then becomes 2:01:20. Oops, we just lost an hour. Next time you reboot, you'll find the time out by an hour or more depending on how many corrections of this type have been done. So, why don't we update the hours and be done with it? We would have to play the same game with the days of the month vs hours. Also, we don't know if the CMOS clock is programmed for UTC time or not (the kernel's idea of time is UTC. Your CMOS may be programmed for EST for instance). Sounds like its still broken then - there are time zones which are not even multiples of 60 minutes. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: set_rtc_mmss: can't update from 0 to 59
On Tue, 19 Dec 2000, Russell King wrote: Oliver Xymoron writes: On Mon, 18 Dec 2000, Russell King wrote: So, why don't we update the hours and be done with it? We would have to play the same game with the days of the month vs hours. Also, we don't know if the CMOS clock is programmed for UTC time or not (the kernel's idea of time is UTC. Your CMOS may be programmed for EST for instance). Sounds like its still broken then - there are time zones which are not even multiples of 60 minutes. Correct; please examine the code and you will find the answer to this. Specifically, look at the lines around the following comment: /* correct for half hour time zone */ Uhh.. Kathmandu? Chatham Island? +5:45 and +13:45 (DST) respectively. At any rate, the printk should go - do_timer_interrupt already expects the "bug" its reporting. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Fri, 15 Dec 2000, Stephen Frost wrote: > * Oliver Xymoron ([EMAIL PROTECTED]) wrote: > > On Thu, 14 Dec 2000, Linus Torvalds wrote: > > > > > A 100ms delay sounds like some interrupt shut up or similar (and then > > > timer handling makes it limp along). > > > > Possibly related datapoint: after several days of uptime, my > > 2.4.0-test10pre? machine went into some sort of slow mode after coming > > back from suspend (and doing an /etc/init.d/networking restart). Symptoms > > seemed to be extra second or so setting up a TCP connection. Ping, etc., > > appeared to work just fine, no packet loss apparent, bandwidth looked good > > too. Sadly I had to do actual work that required zippy web access, so I > > rebooted rather than doing a thorough diagnostic. This is a VAIO with > > compiled in eepro100, no special networking options. > > Actually, I figured out what it was and I feel kind of stupid, and > suprised. I knew I should have tried rebooting before complaining. It > turns out it actually was something in my firewall rules, it appears that > for every logged packet there is something along the lines of a 100ms > delay that gets added on. Hmmm, that's seems rather extreme - does it have to wait for klogd to get scheduled before it proceeds? I would expect the filtering to be down in the noise except at fairly high loads. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Fri, 15 Dec 2000, Stephen Frost wrote: * Oliver Xymoron ([EMAIL PROTECTED]) wrote: On Thu, 14 Dec 2000, Linus Torvalds wrote: A 100ms delay sounds like some interrupt shut up or similar (and then timer handling makes it limp along). Possibly related datapoint: after several days of uptime, my 2.4.0-test10pre? machine went into some sort of slow mode after coming back from suspend (and doing an /etc/init.d/networking restart). Symptoms seemed to be extra second or so setting up a TCP connection. Ping, etc., appeared to work just fine, no packet loss apparent, bandwidth looked good too. Sadly I had to do actual work that required zippy web access, so I rebooted rather than doing a thorough diagnostic. This is a VAIO with compiled in eepro100, no special networking options. Actually, I figured out what it was and I feel kind of stupid, and suprised. I knew I should have tried rebooting before complaining. It turns out it actually was something in my firewall rules, it appears that for every logged packet there is something along the lines of a 100ms delay that gets added on. Hmmm, that's seems rather extreme - does it have to wait for klogd to get scheduled before it proceeds? I would expect the filtering to be down in the noise except at fairly high loads. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Thu, 14 Dec 2000, Linus Torvalds wrote: > On Thu, 14 Dec 2000, Stephen Frost wrote: > > > > Any idea if these issues would cause a general slow-down of a > > machine? For no apparent reason after 5 days running 2.4.0test12 > > everything going through my firewall (set up using iptables) I got about > > 100ms time added on to pings and traceroutes. > > Probably not related to that particular bug - the netfilter issue has > apparently been around forever, and it was just some changes in IP > fragmentation that just made it show up as an oops. > > A 100ms delay sounds like some interrupt shut up or similar (and then > timer handling makes it limp along). Possibly related datapoint: after several days of uptime, my 2.4.0-test10pre? machine went into some sort of slow mode after coming back from suspend (and doing an /etc/init.d/networking restart). Symptoms seemed to be extra second or so setting up a TCP connection. Ping, etc., appeared to work just fine, no packet loss apparent, bandwidth looked good too. Sadly I had to do actual work that required zippy web access, so I rebooted rather than doing a thorough diagnostic. This is a VAIO with compiled in eepro100, no special networking options. Oh, and btw, test12-pre7 seems to have broken my USB camera, which worked with the aforementioned kernel. My build of gphoto2 downloads images via usbdevfs (ugh) and quietly created a bunch of .jpgs that were almost entirely 0s.. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Thu, 14 Dec 2000, Linus Torvalds wrote: On Thu, 14 Dec 2000, Stephen Frost wrote: Any idea if these issues would cause a general slow-down of a machine? For no apparent reason after 5 days running 2.4.0test12 everything going through my firewall (set up using iptables) I got about 100ms time added on to pings and traceroutes. Probably not related to that particular bug - the netfilter issue has apparently been around forever, and it was just some changes in IP fragmentation that just made it show up as an oops. A 100ms delay sounds like some interrupt shut up or similar (and then timer handling makes it limp along). Possibly related datapoint: after several days of uptime, my 2.4.0-test10pre? machine went into some sort of slow mode after coming back from suspend (and doing an /etc/init.d/networking restart). Symptoms seemed to be extra second or so setting up a TCP connection. Ping, etc., appeared to work just fine, no packet loss apparent, bandwidth looked good too. Sadly I had to do actual work that required zippy web access, so I rebooted rather than doing a thorough diagnostic. This is a VAIO with compiled in eepro100, no special networking options. Oh, and btw, test12-pre7 seems to have broken my USB camera, which worked with the aforementioned kernel. My build of gphoto2 downloads images via usbdevfs (ugh) and quietly created a bunch of .jpgs that were almost entirely 0s.. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.2.18-pre19 asm/delay.h problem?
On Wed, 22 Nov 2000, Alan Cox wrote:
> > > |> > > #define __bad_udelay() panic("Udelay called with too large a constant")
> > > |>
> > > |> Can't we change that to :
> > > |> #error "Udelay..."
> > >
> > > No.
> >
> > ?? I think I'm missing something here.
>
> preprocessor stuff is done too early for this
You could still change it to
__bug__module_is_using_a_delay_thats_too_large__please_report()..
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Why not PCMCIA built-in and yenta/i82365 as modules
On Wed, 22 Nov 2000, Matti Aarnio wrote: > On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote: > > The subject says it all. Is there any particular (technical) reason > > why I must have both the generic pcmcia code and the controller support > > built-in, or build all of them as modules? > > > > /Tobias > > Wasn't there some strange laptop model which had PCMCIA floppy/CDROM, > which are unavailable to bootstrap process, unless PCMCIA is supported > at the booting kernel ? > > Or was it about USB floppy at some other laptop? Yes and yes. However, you still would need the controller specific code built-in. The USB floppy situation is uglier still. When I tried to put Debian on my VAIO from floppy, I discovered that even with a USB-enabled kernel, the floppy wasn't available in time to mount /. Approaches that did work, in case anyone is curious, were using loadlin with FreeDOS (incredibly slow) to preload the second floppy via BIOS, or using syslinux and a custom mini-kernel and initrd image crammed onto a single floppy. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: deadlock on 4way machine
On Tue, 21 Nov 2000, Tigran Aivazian wrote: > On 21 Nov 2000, Jes Sorensen wrote: > > > > "Tigran" == Tigran Aivazian <[EMAIL PROTECTED]> writes: > > > > Tigran> Hi, Some processes get stuck in page fault handler for ages > > Tigran> (like for 10 minutes!). The machine still has plenty (3.5G) of > > Tigran> free high memory but zero (2216K) of free low memory. > > > > Including info on the kernel version would kinda help. > > that is obtainable by fingering @finger.kernel.org (I only ever use/report > bugs on the latest kernel). I think only Linus can claim that. At any rate, the world isn't going to remember your particular preference for the latest kernel, nor is it going to go to the trouble of trying to correlate the date on your messages with a history of patch releases. If you report a bug thought to be fixed, it'll just be assumed to be old. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: deadlock on 4way machine
On Tue, 21 Nov 2000, Tigran Aivazian wrote: On 21 Nov 2000, Jes Sorensen wrote: "Tigran" == Tigran Aivazian [EMAIL PROTECTED] writes: Tigran Hi, Some processes get stuck in page fault handler for ages Tigran (like for 10 minutes!). The machine still has plenty (3.5G) of Tigran free high memory but zero (2216K) of free low memory. Including info on the kernel version would kinda help. that is obtainable by fingering @finger.kernel.org (I only ever use/report bugs on the latest kernel). I think only Linus can claim that. At any rate, the world isn't going to remember your particular preference for the latest kernel, nor is it going to go to the trouble of trying to correlate the date on your messages with a history of patch releases. If you report a bug thought to be fixed, it'll just be assumed to be old. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why not PCMCIA built-in and yenta/i82365 as modules
On Wed, 22 Nov 2000, Matti Aarnio wrote: On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote: The subject says it all. Is there any particular (technical) reason why I must have both the generic pcmcia code and the controller support built-in, or build all of them as modules? /Tobias Wasn't there some strange laptop model which had PCMCIA floppy/CDROM, which are unavailable to bootstrap process, unless PCMCIA is supported at the booting kernel ? Or was it about USB floppy at some other laptop? Yes and yes. However, you still would need the controller specific code built-in. The USB floppy situation is uglier still. When I tried to put Debian on my VAIO from floppy, I discovered that even with a USB-enabled kernel, the floppy wasn't available in time to mount /. Approaches that did work, in case anyone is curious, were using loadlin with FreeDOS (incredibly slow) to preload the second floppy via BIOS, or using syslinux and a custom mini-kernel and initrd image crammed onto a single floppy. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.2.18-pre19 asm/delay.h problem?
On Wed, 22 Nov 2000, Alan Cox wrote:
| #define __bad_udelay() panic("Udelay called with too large a constant")
|
| Can't we change that to :
| #error "Udelay..."
No.
?? I think I'm missing something here.
preprocessor stuff is done too early for this
You could still change it to
__bug__module_is_using_a_delay_thats_too_large__please_report()..
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Jeff Garzik wrote: > Oliver Xymoron wrote: > > > > On Mon, 6 Nov 2000, David Woodhouse wrote: > > > > > The point here is that although I've put up with just keeping the sound > > > driver loaded for the last few years, permanently taking up a large amount > > > of DMA memory, the inter_module_xxx stuff that Keith is proposing would > > > give us a simple way of storing the data which we want to store. > > ... > > > Being able to do it completely in userspace would be neater, though. > > > > I think there are a bunch of other devices that need stuff from userspace > > before they fully init, namely the ones that load proprietary firmware > > images. Will an approach like that work here? > > Some devices have a firmware.h that is compiled into the driver. A few > sound devices use a function that loads a firmware file from userspace, > given a filename. The comment in drivers/sound/sound_firmware.c says > that this is a poor method, and that the recommended method for > uploading firmware to a device is via ioctl. Ioctl (or alternate device for plan9 groupies) is fine. My point is final initialization of the device is obviously delayed until the firmware is loaded. Adopting a similar strategy for initializing mixers (possibly falling back to initializing with zero levels) minimizes the window between resetting a device and having sane mixer settings. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: > The point here is that although I've put up with just keeping the sound > driver loaded for the last few years, permanently taking up a large amount > of DMA memory, the inter_module_xxx stuff that Keith is proposing would > give us a simple way of storing the data which we want to store. ... > Being able to do it completely in userspace would be neater, though. I think there are a bunch of other devices that need stuff from userspace before they fully init, namely the ones that load proprietary firmware images. Will an approach like that work here? Alternately, we could have a "virtual module" called mixer-settings-n, which when requested would tell modprobe to call a program to do its fiddly things but wouldn't actually load a module. The virtual module idea is ugly, yes, and perhaps what's needed is a more generic userspace hook interface. Something that merged what /sbin/hotplug, /sbin/modprobe, and the much-talked-about devfsd-like notifier are supposed to do. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: The point here is that although I've put up with just keeping the sound driver loaded for the last few years, permanently taking up a large amount of DMA memory, the inter_module_xxx stuff that Keith is proposing would give us a simple way of storing the data which we want to store. ... Being able to do it completely in userspace would be neater, though. I think there are a bunch of other devices that need stuff from userspace before they fully init, namely the ones that load proprietary firmware images. Will an approach like that work here? Alternately, we could have a "virtual module" called mixer-settings-n, which when requested would tell modprobe to call a program to do its fiddly things but wouldn't actually load a module. The virtual module idea is ugly, yes, and perhaps what's needed is a more generic userspace hook interface. Something that merged what /sbin/hotplug, /sbin/modprobe, and the much-talked-about devfsd-like notifier are supposed to do. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: > On Mon, 6 Nov 2000, Oliver Xymoron wrote: > > > If I understand you correctly: > > > > process 1 process 2 ... > > > Is there any reason we ever want to unblock process 1 before process 2 > > terminates? > > No, and I don't think we do. That's not the point. > > 'init module' is still _after_ 'set mixer levels'. There is a period > during which the mixer levels are changed. Perhaps you mean before? Otherwise you've lost me. > The desired mixer levels should be available to the module at the time of > initialisation. Is this because active audio sources other than /dev/dsp writers are suddenly in and out of the mix? If there's nothing on the inputs, it shouldn't matter whether you're changing the levels. The right way to do this (according to any sound engineer) is to initialize all the levels to zero unless told otherwise. This would doubtless annoy the average user, but is more or less equivalent to not forwarding packets by default. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] document ECN in 2.4 Configure.help
On Sun, 5 Nov 2000, Barry K. Nathan wrote: > +CONFIG_INET_ECN > + Explicit Congestion Notification (ECN) allows routers to notify > + clients about network congestion, resulting in fewer dropped packets > + and increased network performance. This option adds ECN support to the > + Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which > + allows ECN support to be disabled at runtime. You might mention the RFC here, 2481 IIRC. > + Note that, on the Internet, there are many broken firewalls which > + refuse connections from ECN-enabled machines, and it may be a while > + before these firewalls are fixed. Until then, to access a site behind > + such a firewall (some of which are major sites, at the time of this > + writing) you will have to disable this option, either by saying N now > + or by using the sysctl. I'm still not sure why it's been decided not to do fallback or how this whole situation is any different from path MTU discovery. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: > On Mon, 6 Nov 2000, Oliver Xymoron wrote: > > > Hopefully not. The standard examples (mixer levels, etc) are better > > handled with a userspace tool hooked by modprobe. This even gets > > persistence across reboots if that's what's wanted. > > Implement a way for a userspace tool to get the correct mixer levels in > place at the time the sound hardware is reset, so there are no glitches in > the levels, and I'll agree with you. If I understand you correctly: process 1 process 2 open(/dev/dsp) modprobe-> load module init module (can't remember which context, actually) start writing set mixer levels Is there any reason we ever want to unblock process 1 before process 2 terminates? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Keith Owens wrote: > What do people think, do we need module persistent storage? Hopefully not. The standard examples (mixer levels, etc) are better handled with a userspace tool hooked by modprobe. This even gets persistence across reboots if that's what's wanted. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, Keith Owens wrote: What do people think, do we need module persistent storage? Hopefully not. The standard examples (mixer levels, etc) are better handled with a userspace tool hooked by modprobe. This even gets persistence across reboots if that's what's wanted. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
On Mon, 6 Nov 2000, David Woodhouse wrote: On Mon, 6 Nov 2000, Oliver Xymoron wrote: Hopefully not. The standard examples (mixer levels, etc) are better handled with a userspace tool hooked by modprobe. This even gets persistence across reboots if that's what's wanted. Implement a way for a userspace tool to get the correct mixer levels in place at the time the sound hardware is reset, so there are no glitches in the levels, and I'll agree with you. If I understand you correctly: process 1 process 2 open(/dev/dsp) modprobe- load module init module (can't remember which context, actually) start writing set mixer levels Is there any reason we ever want to unblock process 1 before process 2 terminates? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
