Re: [GIT PATCH] Remove devfs from 2.6.12-git
Greg KH writes: > I do care about this, please don't think that. But here's my reasoning > for why it needs to go: [...] > - original developer of devfs has publicly stated udev is a > replacement. Well, that's news to me! > - policy in the kernel. Like sysfs :-) > - clutter and mess In the eye of the beholder. > - code is broken and unfixable No proof. Never say never... Regards, Richard - 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: [GIT PATCH] Remove devfs from 2.6.12-git
Greg KH writes: I do care about this, please don't think that. But here's my reasoning for why it needs to go: [...] - original developer of devfs has publicly stated udev is a replacement. Well, that's news to me! - policy in the kernel. Like sysfs :-) - clutter and mess In the eye of the beholder. - code is broken and unfixable No proof. Never say never... Regards, Richard - 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] swap usage of high memory (fwd)
Linus Torvalds writes: > > On Thu, 19 Jul 2001, Richard Gooch wrote: > > Linus Torvalds writes: > > > Note that the unfair aging (apart from just being a natural > > > requirement of higher allocation pressure) actually has some other > > > advantages too: it ends up being aload balancing thing. Sure, it > > > might throw out some things that get "unfairly" treated, but once we > > > bring them in again we have a better chance of bringing them into a > > > zone that _isn't_ under pressure. > > > > What about moving data to zones with free pages? That would save I/O. > > Well, remember that we _are_ talking about pages that have been aged > (just a bit more aggressively than some other pages), and are not > being used. Well, under memory pressure, those pages may be considered "old" but in fact could be needed again soon. > Dropping them may well be the right thing to do, and migrating them > is potentially very costly indeed (and can cause oscillating > patterns etc horror-schenarios). If you move them, preserving the age and making sure not to evict younger pages in the new zone, that should avoid the oscillations, should it not? Besides, I've seen plenty of oscillations when paging to/from the swap device :-( > Yes, true page migration might eventually be something we have to > start thinking about for NUMA machines, but I'd really really prefer > just about any alternative. Getting a good balance would be _much_ > preferable to having to take out the sledgehammer.. I agree that a good balancing algorithm is required. I'm just suggesting that if you get to the point where you *have* to evict a page from a zone, instead of just tossing it out, move it to another zone if you can. Note that I'm not necessarily suggesting writing dirty pages to another zone instead of to swap. I was originally thinking of just moving "clean" pages (i.e. those that can be freed without the need to schedule I/O) so that potential subsequent I/O to pull them back in may be avoided. Doing proper page migration is a more complex step that needs further consideration. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] swap usage of high memory (fwd)
Linus Torvalds writes: > Note that the unfair aging (apart from just being a natural > requirement of higher allocation pressure) actually has some other > advantages too: it ends up being aload balancing thing. Sure, it > might throw out some things that get "unfairly" treated, but once we > bring them in again we have a better chance of bringing them into a > zone that _isn't_ under pressure. What about moving data to zones with free pages? That would save I/O. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] swap usage of high memory (fwd)
Linus Torvalds writes: Note that the unfair aging (apart from just being a natural requirement of higher allocation pressure) actually has some other advantages too: it ends up being aload balancing thing. Sure, it might throw out some things that get unfairly treated, but once we bring them in again we have a better chance of bringing them into a zone that _isn't_ under pressure. What about moving data to zones with free pages? That would save I/O. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] swap usage of high memory (fwd)
Linus Torvalds writes: On Thu, 19 Jul 2001, Richard Gooch wrote: Linus Torvalds writes: Note that the unfair aging (apart from just being a natural requirement of higher allocation pressure) actually has some other advantages too: it ends up being aload balancing thing. Sure, it might throw out some things that get unfairly treated, but once we bring them in again we have a better chance of bringing them into a zone that _isn't_ under pressure. What about moving data to zones with free pages? That would save I/O. Well, remember that we _are_ talking about pages that have been aged (just a bit more aggressively than some other pages), and are not being used. Well, under memory pressure, those pages may be considered old but in fact could be needed again soon. Dropping them may well be the right thing to do, and migrating them is potentially very costly indeed (and can cause oscillating patterns etc horror-schenarios). If you move them, preserving the age and making sure not to evict younger pages in the new zone, that should avoid the oscillations, should it not? Besides, I've seen plenty of oscillations when paging to/from the swap device :-( Yes, true page migration might eventually be something we have to start thinking about for NUMA machines, but I'd really really prefer just about any alternative. Getting a good balance would be _much_ preferable to having to take out the sledgehammer.. I agree that a good balancing algorithm is required. I'm just suggesting that if you get to the point where you *have* to evict a page from a zone, instead of just tossing it out, move it to another zone if you can. Note that I'm not necessarily suggesting writing dirty pages to another zone instead of to swap. I was originally thinking of just moving clean pages (i.e. those that can be freed without the need to schedule I/O) so that potential subsequent I/O to pull them back in may be avoided. Doing proper page migration is a more complex step that needs further consideration. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: mounting a fs in two places at once?
Alexander Viro writes: > > > On Sun, 24 Jun 2001, Marty Leisner wrote: > > > I just installed redhat 7.1 on a system. > > > > Cleaning up, a made a fs for home...(mounted on /mnt > > to write the stuff to it) > > > > Then I accidently mounted it on /home. > > > > So it was mounted on /home and /mnt at the same time. > > (I didn't bother going in to see what was there). > > Same tree, obviously. > > > Shouldn't this NOT happen? > > Sigh... Guys, who maintains l-k FAQ? You mean the LK mailing list FAQ? That would be me. > Q: I've mounted filesystem in two different places and it worked. Why? > A: Because you've asked to do that. Yes, it works. No, it's not a bug. > > Q: what should I do to unmount it? > A: umount > > Q: but that took care only of one of them. How can I deal with another? > A: umount Patches to the LKML FAQ accepted :-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] rio500 devfs support
Gregory T. Norris writes: > > --qlTNgmc+xy1dBmNv > Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" > Content-Disposition: inline Yuk! MIME! > --0F1p//8PRICkK4MW > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable Horrors! Quoted-printables! > Here's an updated version of the patch - the only real difference is > that rio500.c will printk an error message if devfs_register() fails.=20 > I left that out originally because devfs logs the error, but it's > probably a good idea to indicate which driver made the request. No, it's a bad idea to test the error from devfs_register() unless you *really* have a good reason. Most people who think they have a good reason actually don't, they're just confused :-) The reason you don't want to test the return value is that way the driver works fine with CONFIG_DEVFS=n. Otherwise, you have a driver that doesn't work with devfs, or you have to put ugly #ifdef's in the code. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] rio500 devfs support
Gregory T. Norris writes: --qlTNgmc+xy1dBmNv Content-Type: multipart/mixed; boundary=0F1p//8PRICkK4MW Content-Disposition: inline Yuk! MIME! --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Horrors! Quoted-printables! Here's an updated version of the patch - the only real difference is that rio500.c will printk an error message if devfs_register() fails.=20 I left that out originally because devfs logs the error, but it's probably a good idea to indicate which driver made the request. No, it's a bad idea to test the error from devfs_register() unless you *really* have a good reason. Most people who think they have a good reason actually don't, they're just confused :-) The reason you don't want to test the return value is that way the driver works fine with CONFIG_DEVFS=n. Otherwise, you have a driver that doesn't work with devfs, or you have to put ugly #ifdef's in the code. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: mounting a fs in two places at once?
Alexander Viro writes: On Sun, 24 Jun 2001, Marty Leisner wrote: I just installed redhat 7.1 on a system. Cleaning up, a made a fs for home...(mounted on /mnt to write the stuff to it) Then I accidently mounted it on /home. So it was mounted on /home and /mnt at the same time. (I didn't bother going in to see what was there). Same tree, obviously. Shouldn't this NOT happen? Sigh... Guys, who maintains l-k FAQ? You mean the LK mailing list FAQ? That would be me. Q: I've mounted filesystem in two different places and it worked. Why? A: Because you've asked to do that. Yes, it works. No, it's not a bug. Q: what should I do to unmount it? A: umount mountpoint Q: but that took care only of one of them. How can I deal with another? A: umount another_mountpoint Patches to the LKML FAQ accepted :-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Alan Cox quote? (was: Re: accounting for threads)
Alexander Viro writes: > BTW, proc_net_create() is also not a good idea if you block the > interrupts. Ditto for netlink_kernel_create(), AFAICS (due to > netlink_kernel_creat() -> sock_alloc() -> get_empty_inode() -> > kmem_cache_alloc() with SLAB_KERNEL). > > That, BTW, is a nice illustration - it's easy to get a preemption > point without noticing, so holding spinlocks, let alone disabling > interrupts over the large area is going to hurt like hell. Here's an idea: add a CONFIGable debug mode for spinlock/cli interaction with GFP_KERNEL and other (known) blocking operations. Keep a per-CPU flag or bitmask that's manipulated by lock/cli operations and checked by memory allocators and other key blocking operations. Generate an Oops upon violation. Make the CONFIG option initially set to 'y' for a patch level or two. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Alan Cox quote? (was: Re: accounting for threads)
Alexander Viro writes: BTW, proc_net_create() is also not a good idea if you block the interrupts. Ditto for netlink_kernel_create(), AFAICS (due to netlink_kernel_creat() - sock_alloc() - get_empty_inode() - kmem_cache_alloc() with SLAB_KERNEL). That, BTW, is a nice illustration - it's easy to get a preemption point without noticing, so holding spinlocks, let alone disabling interrupts over the large area is going to hurt like hell. Here's an idea: add a CONFIGable debug mode for spinlock/cli interaction with GFP_KERNEL and other (known) blocking operations. Keep a per-CPU flag or bitmask that's manipulated by lock/cli operations and checked by memory allocators and other key blocking operations. Generate an Oops upon violation. Make the CONFIG option initially set to 'y' for a patch level or two. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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 latest Microsoft FUD. This time from BillG, himself.
Larry McVoy writes: > On Wed, Jun 20, 2001 at 11:09:10PM +0100, Alan Cox wrote: > > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > > > > > Of course the URL that goes with that is : > > http://www.microsoft.com/windows2000/interix/features.asp > > > > Yes., Microsoft ship GNU C (quite legally) as part of their offerings... > > Which brings up an interesting question for us all. Let's postulate, for > the sake of discussion, that we agree on the following: > > a) Linux (or just about any Unix) is a better low level OS than NT > b) Microsoft's application infrastructure is better (the COM layer, >the stuff that lets apps talk to each, the desktop, etc). > > I know we can argue that KDE/GNOME/whatever is going to get there or is > there or is better, etc., but for the time being lets just pretend that > the Microsoft stuff is better. > > What would be wrong with Microsoft/Linux? It would be: > > a) the Linux kernel > b) the Microsoft API ported to X > c) Microsoft apps > d) Linux apps > > Since Microsoft is all about making money, it doesn't matter if they > charge for the dll's or the OS, either one is fine, you can't run Word > without them. If you don't need the Microsoft apps, you could strip > them off and strip off the dlls and ship all the rest of it without > giving Microsoft a dime. If you do need the apps or you want the app > infrastructure, you have to give Microsoft exactly what you have to give > them today - money - but you can run Word side by side with Ghostview > or whatever. Microsoft could charge exactly the same amount for the > dll's as they charge for the OS, none of the end users can tell the > difference anyway. > > I'm unimpressed with what Microsoft calls an operating system and > I'm equally unimpressed with what Unix calls an application layer. > For the last 10 years, Unix has gotten the OS right and the apps wrong > and Microsoft has gotten the apps right and the OS wrong. Seems like > there is potential for a win-win. > > You can scream all you want that "it isn't free software" but the > fact of the matter is that you all scream that and then go do your > slides for your Linux talks in PowerPoint. Actually, it wouldn't bother me at all if they did that. If they didn't violate the GPL (i.e. didn't make proprietary changes to the kernel and libc and various utilities). I guess they could make proprietary hacks to X, which I wouldn't want, otherwise I expect that normal X apps would become 2nd class citizens. If people want to pay for M$ office I'd much rather see them using Linux underneath. That way they have a decent OS and the chances of them being slowly weaned away from M$ products as free alternatives become available (or they get comfortable with the idea of free alternatives). Trying to get people to change wholesale is a lot harder. I suspect M$ doesn't want to do this, because while they could keep flogging Office for a long time (I hear it's better than the alternatives), they would find it harder to flog all the smaller ancillary programmes, as there would be more viable alternatives. I expect M$ will hang on to the bitter end. There's also a lot of emotional attachment to their OS which is driving their policy, I bet. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: [RFC] Early flush (was: spindown)
Daniel Phillips writes: > On Wednesday 20 June 2001 06:39, Richard Gooch wrote: > > Starting I/O immediately if there is no load sounds nice. However, > > what about the other case, when the disc is already spun down (and > > hence there's no I/O load either)? I want the system to avoid doing > > writes while the disc is spun down. I'm quite happy for the system to > > accumulate dirtied pages/buffers, reclaiming clean pages as needed, > > until it absolutely has to start writing out (or I call sync(2)). > > I'd like that too, but what about sync writes? As things stand now, > there is no option but to spin the disk back up. To get around this > we'd have to change the basic behavior of the block device and > that's doable, but it's an entirely different proposition than the > little patch above. I don't care as much about sync writes. They don't seem to happen very often on my boxes. > You know about this project no doubt: > >http://noflushd.sourceforge.net/ Only vaguely. It's huge. Over 2300 lines of C code and >560 lines in .h files! As you say, not really lightweight. There must be a better way. Also, I suspect (without having looked at the code) that it doesn't handle memory pressure well. Things may get nasty when we run low on free pages. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: [RFC] Early flush (was: spindown)
Daniel Phillips writes: On Wednesday 20 June 2001 06:39, Richard Gooch wrote: Starting I/O immediately if there is no load sounds nice. However, what about the other case, when the disc is already spun down (and hence there's no I/O load either)? I want the system to avoid doing writes while the disc is spun down. I'm quite happy for the system to accumulate dirtied pages/buffers, reclaiming clean pages as needed, until it absolutely has to start writing out (or I call sync(2)). I'd like that too, but what about sync writes? As things stand now, there is no option but to spin the disk back up. To get around this we'd have to change the basic behavior of the block device and that's doable, but it's an entirely different proposition than the little patch above. I don't care as much about sync writes. They don't seem to happen very often on my boxes. You know about this project no doubt: http://noflushd.sourceforge.net/ Only vaguely. It's huge. Over 2300 lines of C code and 560 lines in .h files! As you say, not really lightweight. There must be a better way. Also, I suspect (without having looked at the code) that it doesn't handle memory pressure well. Things may get nasty when we run low on free pages. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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 latest Microsoft FUD. This time from BillG, himself.
Larry McVoy writes: On Wed, Jun 20, 2001 at 11:09:10PM +0100, Alan Cox wrote: http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html Of course the URL that goes with that is : http://www.microsoft.com/windows2000/interix/features.asp Yes., Microsoft ship GNU C (quite legally) as part of their offerings... Which brings up an interesting question for us all. Let's postulate, for the sake of discussion, that we agree on the following: a) Linux (or just about any Unix) is a better low level OS than NT b) Microsoft's application infrastructure is better (the COM layer, the stuff that lets apps talk to each, the desktop, etc). I know we can argue that KDE/GNOME/whatever is going to get there or is there or is better, etc., but for the time being lets just pretend that the Microsoft stuff is better. What would be wrong with Microsoft/Linux? It would be: a) the Linux kernel b) the Microsoft API ported to X c) Microsoft apps d) Linux apps Since Microsoft is all about making money, it doesn't matter if they charge for the dll's or the OS, either one is fine, you can't run Word without them. If you don't need the Microsoft apps, you could strip them off and strip off the dlls and ship all the rest of it without giving Microsoft a dime. If you do need the apps or you want the app infrastructure, you have to give Microsoft exactly what you have to give them today - money - but you can run Word side by side with Ghostview or whatever. Microsoft could charge exactly the same amount for the dll's as they charge for the OS, none of the end users can tell the difference anyway. I'm unimpressed with what Microsoft calls an operating system and I'm equally unimpressed with what Unix calls an application layer. For the last 10 years, Unix has gotten the OS right and the apps wrong and Microsoft has gotten the apps right and the OS wrong. Seems like there is potential for a win-win. You can scream all you want that it isn't free software but the fact of the matter is that you all scream that and then go do your slides for your Linux talks in PowerPoint. Actually, it wouldn't bother me at all if they did that. If they didn't violate the GPL (i.e. didn't make proprietary changes to the kernel and libc and various utilities). I guess they could make proprietary hacks to X, which I wouldn't want, otherwise I expect that normal X apps would become 2nd class citizens. If people want to pay for M$ office I'd much rather see them using Linux underneath. That way they have a decent OS and the chances of them being slowly weaned away from M$ products as free alternatives become available (or they get comfortable with the idea of free alternatives). Trying to get people to change wholesale is a lot harder. I suspect M$ doesn't want to do this, because while they could keep flogging Office for a long time (I hear it's better than the alternatives), they would find it harder to flog all the smaller ancillary programmes, as there would be more viable alternatives. I expect M$ will hang on to the bitter end. There's also a lot of emotional attachment to their OS which is driving their policy, I bet. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: [RFC] Early flush (was: spindown)
Daniel Phillips writes: > I never realized how much I didn't like the good old 5 second delay > between saving an edit and actually getting it written to disk until > it went away. Now the question is, did I lose any performance in > doing that. What I wrote in the previous email turned out to be > pretty accurate, so I'll just quote it Starting I/O immediately if there is no load sounds nice. However, what about the other case, when the disc is already spun down (and hence there's no I/O load either)? I want the system to avoid doing writes while the disc is spun down. I'm quite happy for the system to accumulate dirtied pages/buffers, reclaiming clean pages as needed, until it absolutely has to start writing out (or I call sync(2)). Right now I hack that by setting bdflush parameters to 5 minutes. But that's not ideal either. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
Bind oddity/trap
Hi, Al. Here's an oddity I just ran across with VFS bindings: # mkfifo /dev/modem (BTW: it would be nice not to have to make the node) # mount --bind /dev/tts/0 /dev/modem # kermit kermit> set line /dev/modem kermit> set speed 4800 ?Sorry, you must SET LINE first The reason this is happening is because Kermit will do a readdir(2), scanning /dev for a node with the same inum as it gets from fstat(2). In this case, fstat(2) is giving the inum of /dev/tts/0, which is of course the correct behaviour. However, the d_ino field from readdir(2) is giving the inum of the "mount point" (the FIFO I created). So there is an inconsistency, and kermit gets confused. Perhaps readdir(2) should return the same inum as fstat(2) does? I realise that could be quite nasty to implement. However, it is an inconsistency, and a potential trap. But there probably isn't a good solution to this one. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Alan Cox quote?
Larry McVoy writes: > Great, then we are in violent agreement on the single abstraction. > On the second part, I stand by my previous statements that threads or > processes should be used sparingly. > > All I'm doing is trying to counter all the "threads are great" hype. > This is a pretty intelligent pile of people but there are also a fair > number of people who read this list looking for nuggets of information. > If they walk away going "(a) Linux has a cool threading model, and > (b) I should only use threads if I absolutely have to do so and even > then if there are more than there are CPUs I'm probably making a > mistake", if they get that message, that's a good thing, IMHO. New FAQ entry: http://www.tux.org/lkml/#s7-21 Yeah, it's probably a bit harsh :-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Alan Cox quote?
Larry McVoy writes: Great, then we are in violent agreement on the single abstraction. On the second part, I stand by my previous statements that threads or processes should be used sparingly. All I'm doing is trying to counter all the threads are great hype. This is a pretty intelligent pile of people but there are also a fair number of people who read this list looking for nuggets of information. If they walk away going (a) Linux has a cool threading model, and (b) I should only use threads if I absolutely have to do so and even then if there are more than there are CPUs I'm probably making a mistake, if they get that message, that's a good thing, IMHO. New FAQ entry: http://www.tux.org/lkml/#s7-21 Yeah, it's probably a bit harsh :-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
Bind oddity/trap
Hi, Al. Here's an oddity I just ran across with VFS bindings: # mkfifo /dev/modem (BTW: it would be nice not to have to make the node) # mount --bind /dev/tts/0 /dev/modem # kermit kermit set line /dev/modem kermit set speed 4800 ?Sorry, you must SET LINE first The reason this is happening is because Kermit will do a readdir(2), scanning /dev for a node with the same inum as it gets from fstat(2). In this case, fstat(2) is giving the inum of /dev/tts/0, which is of course the correct behaviour. However, the d_ino field from readdir(2) is giving the inum of the mount point (the FIFO I created). So there is an inconsistency, and kermit gets confused. Perhaps readdir(2) should return the same inum as fstat(2) does? I realise that could be quite nasty to implement. However, it is an inconsistency, and a potential trap. But there probably isn't a good solution to this one. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: [RFC] Early flush (was: spindown)
Daniel Phillips writes: I never realized how much I didn't like the good old 5 second delay between saving an edit and actually getting it written to disk until it went away. Now the question is, did I lose any performance in doing that. What I wrote in the previous email turned out to be pretty accurate, so I'll just quote it Starting I/O immediately if there is no load sounds nice. However, what about the other case, when the disc is already spun down (and hence there's no I/O load either)? I want the system to avoid doing writes while the disc is spun down. I'm quite happy for the system to accumulate dirtied pages/buffers, reclaiming clean pages as needed, until it absolutely has to start writing out (or I call sync(2)). Right now I hack that by setting bdflush parameters to 5 minutes. But that's not ideal either. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] devfs v181 available
Alexander Viro writes: > > > On Mon, 18 Jun 2001, Richard Gooch wrote: > > > > Irrelevant. BKL provides an exclusion only on non-blocking areas. > > > > Yeah, I know all that. > > So what the hell are you talking about? Never mind. We seem to be talking at cross purposes. We both know how the BKL works and the implications, so there's not much point beating our heads trying to communicate redundant information :-) > > > _Moved_ them there from the callers of these functions. And AFAICS > > > you do need BKL for get_devfs_entry_...(); otherwise relocation of > > > the table will be able to screw you inside of that function. Now, it > > > will merrily screw you anyway in a lot of places, but that's another > > > story. > > > > OK, so it was another global change. > > Moving BKL into the ->readlink() and ->follow_link()? Sure, it was a global > change. About a year ago. > > > Question: assuming data fed to vfs_follow_link() is "safe", does it > > > need the BKL? I can see that vfs_readlink() obviously doesn't need > > it. From reading Documentation/filesystems/Locking I suspect it > > doesn't need the BKL, but the way I read it says "follow_link() method > > does not *have* the BKL already". But that doesn't explicitely say > > whether vfs_follow_link() needs it. > > vfs_follow_link() doesn't need it. Moreover, if data fed to it is > unsafe without BKL, you are screwed even if you take BKL. So > assumption above is bogus - you _never_ need BKL on that call. OK, you didn't see what I was driving at. If I had said "if my data is protected by a semaphore, do I still need the BKL for vfs_follow_link()" I guess it would have been clearer. Anyway, you've answered my question, thanks. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] devfs v181 available
Alexander Viro writes: > On Mon, 18 Jun 2001, Richard Gooch wrote: > > Alexander Viro writes: > > > On Mon, 18 Jun 2001, Richard Gooch wrote: > > > > - Widened locking in and > > > > > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking > > > functions, so BKL is worthless there. > > > > Huh? The BKL will protect against other operations which might cause > > the devfs entry to be unregistered, where those other operations also > > grab the BKL. So, it's an improvement. > > BKL is released as soon as you block. You _do_ regain it when you get > the next timeslice, but in the meanwhile anything could happen. > > > Sure, some operations may cause unregistration without grabbing the > > Irrelevant. BKL provides an exclusion only on non-blocking areas. Yeah, I know all that. > > BKL, but that's orthogonal (and requires more extensive changes). If > > this "widening" is of no use, then what use are the existing grabs of > > the BKL in those functions? You're the one who added them in the first > > place. > > _Moved_ them there from the callers of these functions. And AFAICS > you do need BKL for get_devfs_entry_...(); otherwise relocation of > the table will be able to screw you inside of that function. Now, it > will merrily screw you anyway in a lot of places, but that's another > story. OK, so it was another global change. > BTW, free advice: when you are checking some condition treat the > result as something that can expire. And don't rely on it past the > moment when it might expired. E.g. in case of de->registered result > expires as soon as you do unlock_kernel() _or_ do anything that > might block. Yeah, I know. Fear not: I'll be adding proper locks (spinlocks and semaphores) to the code, continuing the work I started this weekend. I don't like the BKL anyway (too coarse grained), and hope to see it removed entirely one day. Question: assuming data fed to vfs_follow_link() is "safe", does it need the BKL? I can see that vfs_readlink() obviously doesn't need it. From reading Documentation/filesystems/Locking I suspect it doesn't need the BKL, but the way I read it says "follow_link() method does not *have* the BKL already". But that doesn't explicitely say whether vfs_follow_link() needs it. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] devfs v181 available
Alexander Viro writes: > > > On Mon, 18 Jun 2001, Richard Gooch wrote: > > > - Widened locking in and > > No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking > functions, so BKL is worthless there. Huh? The BKL will protect against other operations which might cause the devfs entry to be unregistered, where those other operations also grab the BKL. So, it's an improvement. Sure, some operations may cause unregistration without grabbing the BKL, but that's orthogonal (and requires more extensive changes). If this "widening" is of no use, then what use are the existing grabs of the BKL in those functions? You're the one who added them in the first place. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] devfs v181 available
Alexander Viro writes: On Mon, 18 Jun 2001, Richard Gooch wrote: - Widened locking in devfs_readlink and devfs_follow_link No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking functions, so BKL is worthless there. Huh? The BKL will protect against other operations which might cause the devfs entry to be unregistered, where those other operations also grab the BKL. So, it's an improvement. Sure, some operations may cause unregistration without grabbing the BKL, but that's orthogonal (and requires more extensive changes). If this widening is of no use, then what use are the existing grabs of the BKL in those functions? You're the one who added them in the first place. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] devfs v181 available
Alexander Viro writes: On Mon, 18 Jun 2001, Richard Gooch wrote: Alexander Viro writes: On Mon, 18 Jun 2001, Richard Gooch wrote: - Widened locking in devfs_readlink and devfs_follow_link No, you hadn't. Both vfs_readlink() and vfs_follow_link() are blocking functions, so BKL is worthless there. Huh? The BKL will protect against other operations which might cause the devfs entry to be unregistered, where those other operations also grab the BKL. So, it's an improvement. BKL is released as soon as you block. You _do_ regain it when you get the next timeslice, but in the meanwhile anything could happen. Sure, some operations may cause unregistration without grabbing the Irrelevant. BKL provides an exclusion only on non-blocking areas. Yeah, I know all that. BKL, but that's orthogonal (and requires more extensive changes). If this widening is of no use, then what use are the existing grabs of the BKL in those functions? You're the one who added them in the first place. _Moved_ them there from the callers of these functions. And AFAICS you do need BKL for get_devfs_entry_...(); otherwise relocation of the table will be able to screw you inside of that function. Now, it will merrily screw you anyway in a lot of places, but that's another story. OK, so it was another global change. BTW, free advice: when you are checking some condition treat the result as something that can expire. And don't rely on it past the moment when it might expired. E.g. in case of de-registered result expires as soon as you do unlock_kernel() _or_ do anything that might block. Yeah, I know. Fear not: I'll be adding proper locks (spinlocks and semaphores) to the code, continuing the work I started this weekend. I don't like the BKL anyway (too coarse grained), and hope to see it removed entirely one day. Question: assuming data fed to vfs_follow_link() is safe, does it need the BKL? I can see that vfs_readlink() obviously doesn't need it. From reading Documentation/filesystems/Locking I suspect it doesn't need the BKL, but the way I read it says follow_link() method does not *have* the BKL already. But that doesn't explicitely say whether vfs_follow_link() needs it. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] devfs v181 available
Alexander Viro writes: On Mon, 18 Jun 2001, Richard Gooch wrote: Irrelevant. BKL provides an exclusion only on non-blocking areas. Yeah, I know all that. So what the hell are you talking about? Never mind. We seem to be talking at cross purposes. We both know how the BKL works and the implications, so there's not much point beating our heads trying to communicate redundant information :-) _Moved_ them there from the callers of these functions. And AFAICS you do need BKL for get_devfs_entry_...(); otherwise relocation of the table will be able to screw you inside of that function. Now, it will merrily screw you anyway in a lot of places, but that's another story. OK, so it was another global change. Moving BKL into the -readlink() and -follow_link()? Sure, it was a global change. About a year ago. Question: assuming data fed to vfs_follow_link() is safe, does it need the BKL? I can see that vfs_readlink() obviously doesn't need it. From reading Documentation/filesystems/Locking I suspect it doesn't need the BKL, but the way I read it says follow_link() method does not *have* the BKL already. But that doesn't explicitely say whether vfs_follow_link() needs it. vfs_follow_link() doesn't need it. Moreover, if data fed to it is unsafe without BKL, you are screwed even if you take BKL. So assumption above is bogus - you _never_ need BKL on that call. OK, you didn't see what I was driving at. If I had said if my data is protected by a semaphore, do I still need the BKL for vfs_follow_link() I guess it would have been clearer. Anyway, you've answered my question, thanks. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v181 available
Hi, all. Version 181 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.6-pre3. Highlights of this release: - Answered question posed by Al Viro and removed his comments from - Moved setting of registered flag after other fields are changed - Fixed race between and - Global VFS changes added bogus BKL to devfsd_close(): removed - Widened locking in and - Replaced stack usage with kmalloc - Simplified locking in and fixed memory leak Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v181 available
Hi, all. Version 181 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.6-pre3. Highlights of this release: - Answered question posed by Al Viro and removed his comments from devfs_open - Moved setting of registered flag after other fields are changed - Fixed race between devfsd_close and devfsd_notify_one - Global VFS changes added bogus BKL to devfsd_close(): removed - Widened locking in devfs_readlink and devfs_follow_link - Replaced devfsd_read stack usage with devfsd_ioctl kmalloc - Simplified locking in devfsd_ioctl and fixed memory leak Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] to init/main.c
Daniel Dickman writes: > Here is a small patch to main.c. > > It does the following: > - makes sure that asm/mtrr.h actually gets included, and What the hell is this? It is already included! > - changes formatting in one place as per Documentation/CodingStyle > > --- linux-2.4.5/init/main.c Tue May 22 12:35:42 2001 > +++ linux/init/main.c Sat Jun 16 11:48:42 2001 > @@ -50,7 +50,7 @@ > #endif > > #ifdef CONFIG_MTRR > -# include > +#include > #endif > > #ifdef CONFIG_NUBUS I don't want this change. It's not fixing anything and removes the intentional indentation. And was there a reason not to Cc: me? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] to init/main.c
Daniel Dickman writes: Here is a small patch to main.c. It does the following: - makes sure that asm/mtrr.h actually gets included, and What the hell is this? It is already included! - changes formatting in one place as per Documentation/CodingStyle --- linux-2.4.5/init/main.c Tue May 22 12:35:42 2001 +++ linux/init/main.c Sat Jun 16 11:48:42 2001 @@ -50,7 +50,7 @@ #endif #ifdef CONFIG_MTRR -# include asm/mtrr.h +#include asm/mtrr.h #endif #ifdef CONFIG_NUBUS I don't want this change. It's not fixing anything and removes the intentional indentation. And was there a reason not to Cc: me? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Download process for a "split kernel" (was: obsolete code must die)
Daniel Phillips writes: > On Thursday 14 June 2001 10:34, Alexander Viro wrote: > > On Thu, 14 Jun 2001, Daniel Phillips wrote: > > > This sounds a lot like apt-get, doesn't it? > > > > Folks, RTFFAQ, please. URL is attached to the end of each posting. > > The FAQ blesses the idea of people setting up incremental download > services, condems the idea of asking Linus to change his procedures > to support this. As it should. > It has nothing to say about the idea of leveraging the cml2 code > base to let apt-get configure and build kernels better, which was > the point of my post. That has been left as an excercise for the FAQ reader. > Presumably you want this question added to the FAQ? ;-) Going into this in detail is not the purpose of the FAQ, but a small, concise patch will be looked upon favourably :-) A link to a more detailed page would nicely supplement a small chunk of text. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Download process for a split kernel (was: obsolete code must die)
Daniel Phillips writes: On Thursday 14 June 2001 10:34, Alexander Viro wrote: On Thu, 14 Jun 2001, Daniel Phillips wrote: This sounds a lot like apt-get, doesn't it? Folks, RTFFAQ, please. URL is attached to the end of each posting. The FAQ blesses the idea of people setting up incremental download services, condems the idea of asking Linus to change his procedures to support this. As it should. It has nothing to say about the idea of leveraging the cml2 code base to let apt-get configure and build kernels better, which was the point of my post. That has been left as an excercise for the FAQ reader. Presumably you want this question added to the FAQ? ;-) Going into this in detail is not the purpose of the FAQ, but a small, concise patch will be looked upon favourably :-) A link to a more detailed page would nicely supplement a small chunk of text. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v180 available
Hi, all. Version 180 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Fixed !CONFIG_DEVFS_FS stub declaration of Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v180 available
Hi, all. Version 180 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Fixed !CONFIG_DEVFS_FS stub declaration of devfs_get_info Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Requirement: swap = RAM x 2.5 ??
Jeff Garzik writes: > Richard Gooch wrote: > > > > Jeff Garzik writes: > > > > > > I'm sorry but this is a regression, plain and simple. > > > > > > Previous versons of Linux have worked great on diskless workstations > > > with NO swap. > > > > > > Swap is "extra space to be used if we have it" and nothing else. > > > > Sure. But Linux still works without swap. It's just that if you *do* > > have swap, it works best with 2* RAM. > > Yes, but that's not the point of the discussion. Currently 2*RAM is > more of a requirement than a recommendation. Um, do you mean "2*RAM is required, always", or "2*RAM or more swap is required if swap != 0"? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Requirement: swap = RAM x 2.5 ??
Jeff Garzik writes: > > I'm sorry but this is a regression, plain and simple. > > Previous versons of Linux have worked great on diskless workstations > with NO swap. > > Swap is "extra space to be used if we have it" and nothing else. Sure. But Linux still works without swap. It's just that if you *do* have swap, it works best with 2* RAM. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Break 2.4 VM in five easy steps
Daniel Phillips writes: > On Wednesday 06 June 2001 10:54, Sean Hunter wrote: > > > > Did you try to put twice as much swap as you have RAM ? (e.g. add a > > > 512M swapfile to your box) > > > This is what Linus recommended for 2.4 (swap = 2 * RAM), saying > > > that anything less won't do any good: 2.4 overallocates swap even > > > if it doesn't use it all. So in your case you just have enough swap > > > to map your RAM, and nothing to really swap your apps. > > > > For large memory boxes, this is ridiculous. Should I have 8GB of > > swap? Sure. It's cheap. If you don't mind slumming it, go and buy a 20 GB IDE drive for US$65. I know RAM has gotten a lot cheaper lately (US$66 for a 512 MiB PC133 DIMM), but it's still far more expensive. If you can afford 4 GiB of RAM, you can definately afford 8 GiB of swap. > And laptops with big memories and small disks. That's not that common, though. Usually you get far more disc than RAM on a laptop, just as with a desktop. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Break 2.4 VM in five easy steps
Daniel Phillips writes: On Wednesday 06 June 2001 10:54, Sean Hunter wrote: Did you try to put twice as much swap as you have RAM ? (e.g. add a 512M swapfile to your box) This is what Linus recommended for 2.4 (swap = 2 * RAM), saying that anything less won't do any good: 2.4 overallocates swap even if it doesn't use it all. So in your case you just have enough swap to map your RAM, and nothing to really swap your apps. For large memory boxes, this is ridiculous. Should I have 8GB of swap? Sure. It's cheap. If you don't mind slumming it, go and buy a 20 GB IDE drive for US$65. I know RAM has gotten a lot cheaper lately (US$66 for a 512 MiB PC133 DIMM), but it's still far more expensive. If you can afford 4 GiB of RAM, you can definately afford 8 GiB of swap. And laptops with big memories and small disks. That's not that common, though. Usually you get far more disc than RAM on a laptop, just as with a desktop. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Requirement: swap = RAM x 2.5 ??
Jeff Garzik writes: I'm sorry but this is a regression, plain and simple. Previous versons of Linux have worked great on diskless workstations with NO swap. Swap is extra space to be used if we have it and nothing else. Sure. But Linux still works without swap. It's just that if you *do* have swap, it works best with 2* RAM. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Requirement: swap = RAM x 2.5 ??
Jeff Garzik writes: Richard Gooch wrote: Jeff Garzik writes: I'm sorry but this is a regression, plain and simple. Previous versons of Linux have worked great on diskless workstations with NO swap. Swap is extra space to be used if we have it and nothing else. Sure. But Linux still works without swap. It's just that if you *do* have swap, it works best with 2* RAM. Yes, but that's not the point of the discussion. Currently 2*RAM is more of a requirement than a recommendation. Um, do you mean 2*RAM is required, always, or 2*RAM or more swap is required if swap != 0? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v179 available
Hi, all. Version 179 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Adjusted to account for fix Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v179 available
Hi, all. Version 179 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Adjusted try_modload to account for devfs_generate_path fix Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v178 available
Hi, all. Version 178 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Fixed handling of inverted options in Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v178 available
Hi, all. Version 178 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Fixed handling of inverted options in devfs_setup Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
[PATCH] devfs v177 available
Hi, all. Version 177 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Updated README from master HTML file - Documentation cleanups - Ensure terminates string for root entry Thanks to Tim Jansen <[EMAIL PROTECTED]> - Exported to modules - Make send events to devfsd - Cleaned up option processing in - Fixed bugs in handling symlinks: could leak or cause Oops - Cleaned up directory handling by separating fops Thanks to Alexander Viro <[EMAIL PROTECTED]> Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] fs/devfs/base.c
Akash Jain writes: > hello, > > in fs/devfs/base.c, > the struct devfsd_notify_struct is approx 1056 bytes, allocating it > on a stack of 8k seems unreasonable. here we simply move it to the > heap, i don't think it is a _must_ be on stack type thing I absolutely don't want this patch applied. It's bogus. It is entirely safe to alloc 1 kB on the stack in this code, since it has a short and well-controlled code path from syscall entry to the function. This is not some function that can be called from some random place in the kernel and thus has a random call path. Using the stack is much faster than calling kmalloc() and it also doesn't add to system memory pressure. That's why I did it this way in the first place. Further, it's much safer to use the stack, since the memory is freed automatically. Thus, there's less scope for introducing errors. Please fix your checker to deal with this class of functions which have a well-defined call path. I'd suggest looking at the total stack allocations from syscall entry point all the way to the end function. Ideally, you'd trace the call path to every function, but of course that may be computationally infeasible. Hopefully it's feasible to do this for any function which has a stack allocation which exceeds some threshold. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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] fs/devfs/base.c
Akash Jain writes: hello, in fs/devfs/base.c, the struct devfsd_notify_struct is approx 1056 bytes, allocating it on a stack of 8k seems unreasonable. here we simply move it to the heap, i don't think it is a _must_ be on stack type thing I absolutely don't want this patch applied. It's bogus. It is entirely safe to alloc 1 kB on the stack in this code, since it has a short and well-controlled code path from syscall entry to the function. This is not some function that can be called from some random place in the kernel and thus has a random call path. Using the stack is much faster than calling kmalloc() and it also doesn't add to system memory pressure. That's why I did it this way in the first place. Further, it's much safer to use the stack, since the memory is freed automatically. Thus, there's less scope for introducing errors. Please fix your checker to deal with this class of functions which have a well-defined call path. I'd suggest looking at the total stack allocations from syscall entry point all the way to the end function. Ideally, you'd trace the call path to every function, but of course that may be computationally infeasible. Hopefully it's feasible to do this for any function which has a stack allocation which exceeds some threshold. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Tony Hoyle writes: > Richard Gooch wrote: > > > In fact, hopefully he's still in a dark mood, and he may take up the > > suggestion to bounce mails of the following type: > > - MIME encoded > > - HTML encoded > > - quoted printables (those stupid "=20" things are particuarly hard to > > read). > > Surely it'd be better to get the list to filter them through stripmime? > > I'd be tempted to put a message at the top at the same time: > "*WARNING* The message below was sent by someone too clueless to > configure their email client properly" Well, while that would be somewhat satisfying, there is a problem if the message gets corrupted by this. And since some people send to the list without being subscribed (or, like me, have duplicate filtering), they'll never see that their message was mangled as it passed through the list. Nope, a bounce is better. If you're going to do these things, feedback is essential. The bounce isn't meant to offend the sender, it's designed to let them know what's happening. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Matti Aarnio writes: > On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote: > ... > > Sure, Dave is being bloody-minded, but that's the only way we'll see > > people get off their fat, lazy asses and fix their broken systems. > > In fact, hopefully he's still in a dark mood, and he may take up the > > suggestion to bounce mails of the following type: > > - MIME encoded > > - HTML encoded > > - quoted printables (those stupid "=20" things are particuarly hard to > > read). > > Bounces to where ? To the sender, of course, who is the evil culprit. > And for that matter, people who you do want to punish do run MUAs, > which happily open up everything -- except these bounce reports > VGER generates. But then, vger sends those reports to > linux-kernel-owner, who needs no additional punishment... I don't understand what you mean here. Are you saying that these MUAs which generate horrible messages drop bounces on the floor?!? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Brent D. Norris writes: > > I veto, the whole point of moving to ECN was to make a statement and > > get people to fix their kit. > > > > We will remove these people, that's all. > > Isn't this a problem though because the messge saying that ECN was > enabled was set after ECN was enabled? Thus these people have no > idea what is going on and they probably won't know what to fix until > they do. Dave sent a message out a week or two ago saying he was going to do it soon. And back in January he said he'd be doing it in February. The kernel list FAQ has stated this right at the top, in big, bright red letters. Yesterday, after I saw Dave's announcement, I updated the FAQ to reflect that we're now running ECN. People have had plenty of warning. Think of it as a bonus that it didn't happen back in February. They've had an extra 3 months to sort something out. I note with disgust the number of places which should know better, but still haven't fixed their kit. Most appalling was missionalcriticallinux.com. Shame! Sure, Dave is being bloody-minded, but that's the only way we'll see people get off their fat, lazy asses and fix their broken systems. In fact, hopefully he's still in a dark mood, and he may take up the suggestion to bounce mails of the following type: - MIME encoded - HTML encoded - quoted printables (those stupid "=20" things are particuarly hard to read). Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Alan Cox writes: > > Matti Aarnio writes: > > > I am contemplating to periodically turn off the ECN bit to > > > let email out, but DaveM has veto there. > > > > I veto, the whole point of moving to ECN was to make a statement and > > get people to fix their kit. > > > > We will remove these people, that's all. > > Since HTML email also has a spec can we remove the people who moan > about that too ;) I'm sure M$ Exchange has a spec too. Doesn't mean we should support it. As a community, we need to fight against the darkness. > "MIME, oh mime, how I hate thee. Let me stick pins in you to >count the ways..." -- Ben LaHaise Amen, brother! Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Matti Aarnio writes: On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote: ... Sure, Dave is being bloody-minded, but that's the only way we'll see people get off their fat, lazy asses and fix their broken systems. In fact, hopefully he's still in a dark mood, and he may take up the suggestion to bounce mails of the following type: - MIME encoded - HTML encoded - quoted printables (those stupid =20 things are particuarly hard to read). Bounces to where ? To the sender, of course, who is the evil culprit. And for that matter, people who you do want to punish do run MUAs, which happily open up everything -- except these bounce reports VGER generates. But then, vger sends those reports to linux-kernel-owner, who needs no additional punishment... I don't understand what you mean here. Are you saying that these MUAs which generate horrible messages drop bounces on the floor?!? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Tony Hoyle writes: Richard Gooch wrote: In fact, hopefully he's still in a dark mood, and he may take up the suggestion to bounce mails of the following type: - MIME encoded - HTML encoded - quoted printables (those stupid =20 things are particuarly hard to read). Surely it'd be better to get the list to filter them through stripmime? I'd be tempted to put a message at the top at the same time: *WARNING* The message below was sent by someone too clueless to configure their email client properly Well, while that would be somewhat satisfying, there is a problem if the message gets corrupted by this. And since some people send to the list without being subscribed (or, like me, have duplicate filtering), they'll never see that their message was mangled as it passed through the list. Nope, a bounce is better. If you're going to do these things, feedback is essential. The bounce isn't meant to offend the sender, it's designed to let them know what's happening. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Brent D. Norris writes: I veto, the whole point of moving to ECN was to make a statement and get people to fix their kit. We will remove these people, that's all. Isn't this a problem though because the messge saying that ECN was enabled was set after ECN was enabled? Thus these people have no idea what is going on and they probably won't know what to fix until they do. Dave sent a message out a week or two ago saying he was going to do it soon. And back in January he said he'd be doing it in February. The kernel list FAQ has stated this right at the top, in big, bright red letters. Yesterday, after I saw Dave's announcement, I updated the FAQ to reflect that we're now running ECN. People have had plenty of warning. Think of it as a bonus that it didn't happen back in February. They've had an extra 3 months to sort something out. I note with disgust the number of places which should know better, but still haven't fixed their kit. Most appalling was missionalcriticallinux.com. Shame! Sure, Dave is being bloody-minded, but that's the only way we'll see people get off their fat, lazy asses and fix their broken systems. In fact, hopefully he's still in a dark mood, and he may take up the suggestion to bounce mails of the following type: - MIME encoded - HTML encoded - quoted printables (those stupid =20 things are particuarly hard to read). Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: ECN is on!
Alan Cox writes: Matti Aarnio writes: I am contemplating to periodically turn off the ECN bit to let email out, but DaveM has veto there. I veto, the whole point of moving to ECN was to make a statement and get people to fix their kit. We will remove these people, that's all. Since HTML email also has a spec can we remove the people who moan about that too ;) I'm sure M$ Exchange has a spec too. Doesn't mean we should support it. As a community, we need to fight against the darkness. MIME, oh mime, how I hate thee. Let me stick pins in you to count the ways... -- Ben LaHaise Amen, brother! Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
No Subject
Ph. Marek writes: > in fs/devfs/util.c is > void __init devfs_make_root (const char *name) > which is wrong as pivot_root allows changing the root-device in the runtime. > > I think it should be > void __init devfs_make_root (const char *name) > and get called by > fs/super.c: > asmlinkage long sys_pivot_root(const char *new_root, const char *put_old) > after > chroot_fs_refs(root,root_mnt,new_nd.dentry,new_nd.mnt); > error = 0; > > Is that correct? No, because devfs_mk_root() only ever needs to called from mount_root(). If you're doing pivot_root() then you've got initrd, in which case you can create compatibility symlinks from user-space. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
No Subject
Ph. Marek writes: in fs/devfs/util.c is void __init devfs_make_root (const char *name) which is wrong as pivot_root allows changing the root-device in the runtime. I think it should be void __init devfs_make_root (const char *name) and get called by fs/super.c: asmlinkage long sys_pivot_root(const char *new_root, const char *put_old) after chroot_fs_refs(root,root_mnt,new_nd.dentry,new_nd.mnt); error = 0; Is that correct? No, because devfs_mk_root() only ever needs to called from mount_root(). If you're doing pivot_root() then you've got initrd, in which case you can create compatibility symlinks from user-space. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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
Alexander Viro writes: > > > On Sat, 19 May 2001, Richard Gooch wrote: > > > The transaction(2) syscall can be just as easily abused as ioctl(2) in > > this respect. People can pass pointers to ill-designed structures very > > Right. Moreover, it's not needed. The same functionality can be > trivially implemented by write() and read(). As the matter of fact, > had been done in userland context for decades. Go and buy > Stevens. Read it. Then come back. I don't need to read it. Don't be insulting. Sure, you *can* use a write(2)/read(2) cycle. But that's two syscalls compared to one with ioctl(2) or transaction(2). That can matter to some applications. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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
Matthew Wilcox writes: > On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote: > > Al, if you really want to kill ioctl(2), then perhaps you should > > implement a transaction(2) syscall. Something like: > > int transaction (int fd, void *rbuf, size_t rlen, > > void *wbuf, size_t wlen); > > > > Of course, there wouldn't be any practical gain, since we already have > > ioctl(2). Any gain would be aesthetic. > > I can tell you haven't had to write any 32-bit ioctl emulation code for > a 64-bit kernel recently. The transaction(2) syscall can be just as easily abused as ioctl(2) in this respect. People can pass pointers to ill-designed structures very easily. The main advantage of transaction(2) is that hopefully, people will not be so bone-headed as to forget to pass sizeof *structptr as the size field. So perhaps some error trapping is possible. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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 inuserspace
Andries Brouwer writes: > Andrew Morton writes: > > > > (2) what about bootstrapping? how do you find the root device? > > > Do you do "root=/dev/hda/offset=63,limit=1235823"? Bit nasty. > > > > Ben's patch makes initrd mandatory. > > Can this be fixed? I've *never* had to futz with initrd. > Probably most systems are the same. It seems a step > backward to make it necessary. > > I don't think so. It is necessary, and it is good. It most certainly is not. This attitude of pushing more and more stuff out of the kernel and into initrd is really annoying. Initrd is messy, nasty and opaque. It makes the boot process more complex. There is no way in hell I want to be forced to use it. Removing N lines from the kernel at the cost of adding N+k lines to user-space is a *loss*, not a gain. I want my *system* to be simple and transparent. > But it is easy to make the transition painless. No, initrd is fundamentally painful. Let go of this ideology of removing code from the kernel at all costs. A super-slim kernel which requires a more complex to administer user-space is too high a cost. The benefits of removing partition support from the kernel are basically zero. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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
Alan Cox writes: > > ioctls are evil, period. At least with these names you can use normal > > scripting and don't need any special tools. Every ioctl means a binary > > that has no business to exist. > > That is not IMHO a rational argument. It isn't my fault that your > shell does not support ioctls usefully. If you used perl as your > login shell you would have no problem there. There is another reason to use ioctl(2): when you need to send data to the kernel/driver and wait for a response. It supports transactions, which read(2) and write(2) cannot. Therefore it remains useful. Al, if you really want to kill ioctl(2), then perhaps you should implement a transaction(2) syscall. Something like: int transaction (int fd, void *rbuf, size_t rlen, void *wbuf, size_t wlen); Of course, there wouldn't be any practical gain, since we already have ioctl(2). Any gain would be aesthetic. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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
Alexander Viro writes: On Sat, 19 May 2001, Richard Gooch wrote: The transaction(2) syscall can be just as easily abused as ioctl(2) in this respect. People can pass pointers to ill-designed structures very Right. Moreover, it's not needed. The same functionality can be trivially implemented by write() and read(). As the matter of fact, had been done in userland context for decades. Go and buy Stevens. Read it. Then come back. I don't need to read it. Don't be insulting. Sure, you *can* use a write(2)/read(2) cycle. But that's two syscalls compared to one with ioctl(2) or transaction(2). That can matter to some applications. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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
Matthew Wilcox writes: On Sat, May 19, 2001 at 12:51:23PM -0600, Richard Gooch wrote: Al, if you really want to kill ioctl(2), then perhaps you should implement a transaction(2) syscall. Something like: int transaction (int fd, void *rbuf, size_t rlen, void *wbuf, size_t wlen); Of course, there wouldn't be any practical gain, since we already have ioctl(2). Any gain would be aesthetic. I can tell you haven't had to write any 32-bit ioctl emulation code for a 64-bit kernel recently. The transaction(2) syscall can be just as easily abused as ioctl(2) in this respect. People can pass pointers to ill-designed structures very easily. The main advantage of transaction(2) is that hopefully, people will not be so bone-headed as to forget to pass sizeof *structptr as the size field. So perhaps some error trapping is possible. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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 inuserspace
Andries Brouwer writes: Andrew Morton writes: (2) what about bootstrapping? how do you find the root device? Do you do root=/dev/hda/offset=63,limit=1235823? Bit nasty. Ben's patch makes initrd mandatory. Can this be fixed? I've *never* had to futz with initrd. Probably most systems are the same. It seems a step backward to make it necessary. I don't think so. It is necessary, and it is good. It most certainly is not. This attitude of pushing more and more stuff out of the kernel and into initrd is really annoying. Initrd is messy, nasty and opaque. It makes the boot process more complex. There is no way in hell I want to be forced to use it. Removing N lines from the kernel at the cost of adding N+k lines to user-space is a *loss*, not a gain. I want my *system* to be simple and transparent. But it is easy to make the transition painless. No, initrd is fundamentally painful. Let go of this ideology of removing code from the kernel at all costs. A super-slim kernel which requires a more complex to administer user-space is too high a cost. The benefits of removing partition support from the kernel are basically zero. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
Alan Cox writes:
> > Argh! What I wrote in text is what I meant to say. The code didn't
> > match. No wonder people seemed to be missing the point. So the line of
> > code I actually meant was:
> > if (strcmp (buffer + len - 3, "/cd") != 0) {
>
> drivers/kitchen/bluetooth/vegerack/cd
>
> its the cabbage dicer still ..
No, because it violates the standard. Just as we can define a major
number to have a specific meaning, we can define a name in the devfs
namespace to have a specific meaning.
Yes, it's broken if someone writes a cabbage dicer driver and uses
"cd" as the leaf node name for devfs.
Yes, it's broken if someone writes a cabbage dicer driver and uses
the same major as the IDE CD-ROM or SCSI CD-ROM drivers.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
[Cc: list trimmed because I figure people are getting tired of us:-] H. Peter Anvin writes: > Richard Gooch wrote: > > > > H. Peter Anvin writes: > > > Richard Gooch wrote: > > > > > > > > Erm, let's start again. My central point is that you can use devfs > > > > names to reliably figure out what kind of device a FD is, as a cleaner > > > > alternative to comparing major numbers. Therefore, I'm challenging the > > > > notion that you need to reserve magic major numbers in order to > > > > distinguish devices. > > > > > > Noone in this tree has made that claim. Everyone agree it's > > > butt-ugly. However, your solution is by and large just as > > > butt-ugly. > > > > So you'd prefer some kind of capability list? OK. How do you figure on dealing with the problem of multiple high-level drivers talking to the same device? How does sr.o "know" that this is also a CD-RW? How does sg.o "know" that this is also a tape? Where does the responsibility lie for figuring out the capabilities? Further, which device node/fs/driver exports the capability list? And what about locking between drivers? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes: > Richard Gooch wrote: > > > > Erm, let's start again. My central point is that you can use devfs > > names to reliably figure out what kind of device a FD is, as a cleaner > > alternative to comparing major numbers. Therefore, I'm challenging the > > notion that you need to reserve magic major numbers in order to > > distinguish devices. > > Noone in this tree has made that claim. Everyone agree it's > butt-ugly. However, your solution is by and large just as > butt-ugly. So you'd prefer some kind of capability list? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes: > Richard Gooch wrote: > > We have this aliasing anyway. sg and sr are just one example. If you > > care about conflicts, then make sure the drivers lock each other out. > > It's got nothing to do with the mechanism to find out whether > > something can behave like a CD-ROM or not. > > No fscking way. What you're saying "well, my design is broken, so > break your driver even further." You're suggesting prohibiting > legal (and useful) operations because you're advocating an idiotic > design to identify devices? Give me a break. Erm, let's start again. My central point is that you can use devfs names to reliably figure out what kind of device a FD is, as a cleaner alternative to comparing major numbers. Therefore, I'm challenging the notion that you need to reserve magic major numbers in order to distinguish devices. I suspect you're thinking about a different problem, which is finding out what a device can do. Implementing some kind of capability list may well be a good approach to *that* problem. There are some details to figure out, like how multiple drivers interact with each other. They could be tricky. Now, with the above said, what operations do you think I'm prohibiting? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes: > Ingo Oeser wrote: > > > > We do this already with ide-scsi. A device is visible as /dev/hda > > and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda, > > /dev/sr0 and /dev/sg0. > > > > All at the same time. > > > > ... and if you don't know about this funny aliasing, you get screwed. > This is BAD DESIGN, once again. We have this aliasing anyway. sg and sr are just one example. If you care about conflicts, then make sure the drivers lock each other out. It's got nothing to do with the mechanism to find out whether something can behave like a CD-ROM or not. > > Sorry, I don't see your point here :-( > > That seems to be a common theme with you. C'mon, Peter. No need for that. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > H. Peter Anvin writes:
> > > Richard Gooch wrote:
> > > > Argh! What I wrote in text is what I meant to say. The code didn't
> > > > match. No wonder people seemed to be missing the point. So the line of
> > > > code I actually meant was:
> > > > if (strcmp (buffer + len - 3, "/cd") != 0) {
> > >
> > > This is still a really bad idea. You don't want to tie this kind of
> > > things to the name.
> >
> > Why do you think it's a bad idea?
>
> Because you are now, once again, tying two things that are
> completely and utterly unrelated: device classification and device
> name. It breaks every time someone comes out with a new device
> which is "kind of like an old device, but not really," like
> CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and
> DVD (kind-of-like CD)...
But all devices which export a CD-ROM interface will do so. So the
device node that is associated with the CD-ROM driver will export
CD-ROM semantics, and the trailing name will be "/cd".
Other interfaces a device exports, such as a CD-RW, appear as a
different device node ("generic" for SCSI, because we have no CD-RW
classification at this point).
My scheme works already, and works reliably. Nothing had to be done to
support the CD-ROM interface to CD-RW and DVD devices.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Linus Torvalds writes: > > On Wed, 16 May 2001, Richard Gooch wrote: > > > > > > This is still a really bad idea. You don't want to tie this kind of > > > things to the name. > > > > Why do you think it's a bad idea? > > Well, one reason names are bad is that they don't always exist. > > If you only have the fd (remember that unix notion of using > and ), you'd have no clue where the thing came from. So > something else than the name is certainly a good idea for some of > these issues. But, as I described in my original message, you use /proc/self/fd to find where the fd came from. Or are you saying that you can't rely on having /proc available? Or do you have other reasons not to like the scheme I described? One of the reasons I like it is because it requires no new kernel code. > That said, I still think the real problem is rampant use of ioctl's, > which are a bad idea in the first place. Magic numbers are always > bad, and are a sign of bad design. No argument from me. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes:
> Richard Gooch wrote:
> > Argh! What I wrote in text is what I meant to say. The code didn't
> > match. No wonder people seemed to be missing the point. So the line of
> > code I actually meant was:
> > if (strcmp (buffer + len - 3, "/cd") != 0) {
>
> This is still a really bad idea. You don't want to tie this kind of
> things to the name.
Why do you think it's a bad idea?
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Geert Uytterhoeven writes:
> On Tue, 15 May 2001, Richard Gooch wrote:
> > Alan Cox writes:
> > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a trailing "/cd" is a
> > CD-ROM. That's the standard.
>
> Then check for `/cd' at the end instead of `cd' :-)
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, "/cd") != 0) {
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Andrzej Krzysztofowicz writes:
> >
> > OK, just correct me if I get this wrong, but this code is taking the LAST 2
> > characters of the device name and verifying that it is "cd". Which would
> > mean that the standard states that "/dev/ginsucd" would be a CD-ROM drive?
> >
> > That is why I feel a "name" of a device handle shouldnt set how a driver
> > operates in this fashion... if you make a small error in your compare, you
> > might try to eject a Ginsu Cabbage Dicer instead of a cdrom drive... OOPS!
> >
> > Sam Bingner
> >
> > Alan Cox writes:
> > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a trailing "/cd" is a
> > CD-ROM. That's the standard.
>
> Sure, you no longer support /dev/sdcd (eighty-second SCSI disk)...
Then you haven't looked at what devfs actually does. *All* CD-ROMs
will have a trailing pathname component of "/cd". In other words, the
name of the leaf node in it's parent directory is "cd".
The FAQ describes this.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Andrzej Krzysztofowicz writes:
OK, just correct me if I get this wrong, but this code is taking the LAST 2
characters of the device name and verifying that it is cd. Which would
mean that the standard states that /dev/ginsucd would be a CD-ROM drive?
That is why I feel a name of a device handle shouldnt set how a driver
operates in this fashion... if you make a small error in your compare, you
might try to eject a Ginsu Cabbage Dicer instead of a cdrom drive... OOPS!
Sam Bingner
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
Sure, you no longer support /dev/sdcd (eighty-second SCSI disk)...
Then you haven't looked at what devfs actually does. *All* CD-ROMs
will have a trailing pathname component of /cd. In other words, the
name of the leaf node in it's parent directory is cd.
The FAQ describes this.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Geert Uytterhoeven writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
Then check for `/cd' at the end instead of `cd' :-)
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes:
Richard Gooch wrote:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
This is still a really bad idea. You don't want to tie this kind of
things to the name.
Why do you think it's a bad idea?
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Linus Torvalds writes: On Wed, 16 May 2001, Richard Gooch wrote: This is still a really bad idea. You don't want to tie this kind of things to the name. Why do you think it's a bad idea? Well, one reason names are bad is that they don't always exist. If you only have the fd (remember that unix notion of using stdin and stdout), you'd have no clue where the thing came from. So something else than the name is certainly a good idea for some of these issues. But, as I described in my original message, you use /proc/self/fd to find where the fd came from. Or are you saying that you can't rely on having /proc available? Or do you have other reasons not to like the scheme I described? One of the reasons I like it is because it requires no new kernel code. That said, I still think the real problem is rampant use of ioctl's, which are a bad idea in the first place. Magic numbers are always bad, and are a sign of bad design. No argument from me. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes:
Richard Gooch wrote:
H. Peter Anvin writes:
Richard Gooch wrote:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
This is still a really bad idea. You don't want to tie this kind of
things to the name.
Why do you think it's a bad idea?
Because you are now, once again, tying two things that are
completely and utterly unrelated: device classification and device
name. It breaks every time someone comes out with a new device
which is kind of like an old device, but not really, like
CD-writers (which was kind-of-like WORM, kind-of-like CD-ROM) and
DVD (kind-of-like CD)...
But all devices which export a CD-ROM interface will do so. So the
device node that is associated with the CD-ROM driver will export
CD-ROM semantics, and the trailing name will be /cd.
Other interfaces a device exports, such as a CD-RW, appear as a
different device node (generic for SCSI, because we have no CD-RW
classification at this point).
My scheme works already, and works reliably. Nothing had to be done to
support the CD-ROM interface to CD-RW and DVD devices.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes: Ingo Oeser wrote: We do this already with ide-scsi. A device is visible as /dev/hda and /dev/sda at the same time. Or think IDE-CDRW: /dev/hda, /dev/sr0 and /dev/sg0. All at the same time. ... and if you don't know about this funny aliasing, you get screwed. This is BAD DESIGN, once again. We have this aliasing anyway. sg and sr are just one example. If you care about conflicts, then make sure the drivers lock each other out. It's got nothing to do with the mechanism to find out whether something can behave like a CD-ROM or not. Sorry, I don't see your point here :-( That seems to be a common theme with you. C'mon, Peter. No need for that. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes: Richard Gooch wrote: We have this aliasing anyway. sg and sr are just one example. If you care about conflicts, then make sure the drivers lock each other out. It's got nothing to do with the mechanism to find out whether something can behave like a CD-ROM or not. No fscking way. What you're saying well, my design is broken, so break your driver even further. You're suggesting prohibiting legal (and useful) operations because you're advocating an idiotic design to identify devices? Give me a break. Erm, let's start again. My central point is that you can use devfs names to reliably figure out what kind of device a FD is, as a cleaner alternative to comparing major numbers. Therefore, I'm challenging the notion that you need to reserve magic major numbers in order to distinguish devices. I suspect you're thinking about a different problem, which is finding out what a device can do. Implementing some kind of capability list may well be a good approach to *that* problem. There are some details to figure out, like how multiple drivers interact with each other. They could be tricky. Now, with the above said, what operations do you think I'm prohibiting? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
H. Peter Anvin writes: Richard Gooch wrote: Erm, let's start again. My central point is that you can use devfs names to reliably figure out what kind of device a FD is, as a cleaner alternative to comparing major numbers. Therefore, I'm challenging the notion that you need to reserve magic major numbers in order to distinguish devices. Noone in this tree has made that claim. Everyone agree it's butt-ugly. However, your solution is by and large just as butt-ugly. So you'd prefer some kind of capability list? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
[Cc: list trimmed because I figure people are getting tired of us:-] H. Peter Anvin writes: Richard Gooch wrote: H. Peter Anvin writes: Richard Gooch wrote: Erm, let's start again. My central point is that you can use devfs names to reliably figure out what kind of device a FD is, as a cleaner alternative to comparing major numbers. Therefore, I'm challenging the notion that you need to reserve magic major numbers in order to distinguish devices. Noone in this tree has made that claim. Everyone agree it's butt-ugly. However, your solution is by and large just as butt-ugly. So you'd prefer some kind of capability list? OK. How do you figure on dealing with the problem of multiple high-level drivers talking to the same device? How does sr.o know that this is also a CD-RW? How does sg.o know that this is also a tape? Where does the responsibility lie for figuring out the capabilities? Further, which device node/fs/driver exports the capability list? And what about locking between drivers? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
Alan Cox writes:
Argh! What I wrote in text is what I meant to say. The code didn't
match. No wonder people seemed to be missing the point. So the line of
code I actually meant was:
if (strcmp (buffer + len - 3, /cd) != 0) {
drivers/kitchen/bluetooth/vegerack/cd
its the cabbage dicer still ..
No, because it violates the standard. Just as we can define a major
number to have a specific meaning, we can define a name in the devfs
namespace to have a specific meaning.
Yes, it's broken if someone writes a cabbage dicer driver and uses
cd as the leaf node name for devfs.
Yes, it's broken if someone writes a cabbage dicer driver and uses
the same major as the IDE CD-ROM or SCSI CD-ROM drivers.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Alan Cox writes:
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a trailing "/cd" is a
> > CD-ROM. That's the standard.
>
> And its back to /dev/disc versus /dev/disk. Dont muddle user picked
> file names with kernel namespace bindings please.
Even if we have per-device filesystems, we are going to have the same
issue, in one form or another. If we have a "/devicetype" trailing
component added on, then somewhere it has to report "CD-ROM" or "cd"
or "Compact Disc".
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Alexander Viro writes:
>
>
> On Tue, 15 May 2001, Richard Gooch wrote:
>
> > Alan Cox writes:
> > > > len = readlink ("/proc/self/3", buffer, buflen);
> > > > if (strcmp (buffer + len - 2, "cd") != 0) {
> > > > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > > > exit (1);
> > >
> > > And on my box cd is the cabbage dicer whoops
> >
> > Actually, no, because it's guaranteed that a trailing "/cd" is a
> > CD-ROM. That's the standard.
>
> Set by...?
Me The device name authority (Peter). Whoever. If you want
Peter to bless it, then fine. But the standard is there. Violators
will be persecuted.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Alan Cox writes:
> > len = readlink ("/proc/self/3", buffer, buflen);
> > if (strcmp (buffer + len - 2, "cd") != 0) {
> > fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
> > exit (1);
>
> And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing "/cd" is a
CD-ROM. That's the standard.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Ingo Oeser writes:
> On Tue, May 15, 2001 at 08:10:29AM -0700, Linus Torvalds wrote:
> > and I don't see why we couldn't expose the "driver
> > name" for any file descriptor.
>
> Because we dont like to replace:
>
>if (st.device == MAJOR_1)
> bla
>else if ...
>
> with
>
>if (!strcmp(st.device,"driver_1") )
> bla
>else if ...
>
> ?
>
> There is no win doing it this way, because every time we add a
> new driver that fits or change the name of one, we need add
> support for it.
Now look at how we can already do these things with devfs. Let's say
I've opened /dev/cdroms/cdrom0 and it's sitting on fd=3.
% ls -lF /proc/self/fd/3
lrwx-- 1 root root 64 May 15 13:24 /proc/self/fd/3 ->
/dev/ide/host0/bus0/target1/lun0/cd
So, in my application I do:
len = readlink ("/proc/self/3", buffer, buflen);
if (strcmp (buffer + len - 2, "cd") != 0) {
fprintf (stderr, "Not a CD-ROM! Bugger off.\n");
exit (1);
}
if (strncmp (buffer, "/dev/ide", 8) == 0) do_ide (fd);
else if (strncmp (buffer, "/dev/scsi", 9) == 0) do_scsi (fd);
else do_generic (fd);
That's a lot cleaner than relying on magic numbers, IMNSHO.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: Getting FS access events
Linus Torvalds writes: > > On Tue, 15 May 2001, Richard Gooch wrote: > > > > However, what about simply invalidating an entry in the buffer cache > > when you do a write from the page cache? > > And how do you do the invalidate the other way, pray tell? > > What happens if you create a buffer cache entry? Does that > invalidate the page cache one? Or do you just allow invalidates one > way, and not the other? And why= I just figured on one way invalidates, because that seems cheap and easy and has some benefits. Invalidating the other way is costly, so don't bother, even if there were some benefits. > > Actually, I'd kind of like it if the page cache steals from the buffer > > cache on read. The buffer cache is mostly populated by fsck. Once I've > > done the fsck, those buffers are useless to me. They might be useful > > again if they are steal-able by the page cache. > > Ehh.. And then you'll be unhappy _again_, when we early in 2.5.x > start using the page cache for block device accesses. Which we > _have_ to do if we want to be able to mmap block devices. Which we > _do_ want to do (hint: DVD's etc). So what happens if I dd from the block device and also from a file on the mounted FS, where that file overlaps the bnums I dd'ed? Do we get two copies in the page cache? One for the block device access, and one for the file access? > Face it. What you ask for is stupid and fundamentally unworkable. > > Tell me WHY you are completely ignoring my arguments, when I (a) > tell you why your way is bad and stupid (and when you ignore the > arguments, don't complain when I call you stupid) and (b) I give you > alternate ways to do the same thing, except my suggestion is > _faster_ and has none of the downside yours has. > > WHY? Because I like to understand completely all the different options before giving up on any. That in itself is a good enough reason, IMO. Because I've found that when arguing about this kind of stuff, even if the other person asks for something that is "wrong" or "stupid" from your own point of view, if you respect their intelligence, then maybe you can together find an alternative solution that solves the underlying problem but does it cleanly. I've been on the other side of this with a friend and colleague. We used to have healthy arguments that lasted all afternoon. He'd ask for something that was unclean and didn't fit into the structure or the philosophy. But I respected his intelligence, skill and his need for a solution. In the end, we'd come up with a better way than either one would have proposed. We had a dialogue. And because your suspend/resume idea isn't really going to help me much. That's because my boot scripts have the notion of "personalities" (change the boot configuration by asking the user early on in the boot process). If I suspend after I've got XDM running, it's too late. So what I want is a solution that will keep the kernel clean (believe me, I really do want to keep it clean), but gives me a fast boot too. And I believe the solution is out there. We just haven't found it yet. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Getting FS access events
Linus Torvalds writes: > You could choose to do "partial coherency", ie be coherent only one > way, for example. That would make the coherency overhead much less, > but would also make the caches basically act very unpredictably - > you might have somebody write through the page cache yet on a read > actually not _see_ what he wrote, because it got written out to disk > and was shadowed by cached data in the buffer cache that didn't get > updated. OK, I see your concern. And the old way of doing things, placing a copy in the buffer cache when the page cache does a write, will eat away performance. However, what about simply invalidating an entry in the buffer cache when you do a write from the page cache? By the time you get ready to do the I/O, you have the device bnum, so then isn't it a trivial operation to index into the buffer cache and invalidate that block? Is there some other subtlety I'm missing here? Actually, I'd kind of like it if the page cache steals from the buffer cache on read. The buffer cache is mostly populated by fsck. Once I've done the fsck, those buffers are useless to me. They might be useful again if they are steal-able by the page cache. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Getting FS access events
Linus Torvalds writes: You could choose to do partial coherency, ie be coherent only one way, for example. That would make the coherency overhead much less, but would also make the caches basically act very unpredictably - you might have somebody write through the page cache yet on a read actually not _see_ what he wrote, because it got written out to disk and was shadowed by cached data in the buffer cache that didn't get updated. OK, I see your concern. And the old way of doing things, placing a copy in the buffer cache when the page cache does a write, will eat away performance. However, what about simply invalidating an entry in the buffer cache when you do a write from the page cache? By the time you get ready to do the I/O, you have the device bnum, so then isn't it a trivial operation to index into the buffer cache and invalidate that block? Is there some other subtlety I'm missing here? Actually, I'd kind of like it if the page cache steals from the buffer cache on read. The buffer cache is mostly populated by fsck. Once I've done the fsck, those buffers are useless to me. They might be useful again if they are steal-able by the page cache. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: Getting FS access events
Linus Torvalds writes: On Tue, 15 May 2001, Richard Gooch wrote: However, what about simply invalidating an entry in the buffer cache when you do a write from the page cache? And how do you do the invalidate the other way, pray tell? What happens if you create a buffer cache entry? Does that invalidate the page cache one? Or do you just allow invalidates one way, and not the other? And why= I just figured on one way invalidates, because that seems cheap and easy and has some benefits. Invalidating the other way is costly, so don't bother, even if there were some benefits. Actually, I'd kind of like it if the page cache steals from the buffer cache on read. The buffer cache is mostly populated by fsck. Once I've done the fsck, those buffers are useless to me. They might be useful again if they are steal-able by the page cache. Ehh.. And then you'll be unhappy _again_, when we early in 2.5.x start using the page cache for block device accesses. Which we _have_ to do if we want to be able to mmap block devices. Which we _do_ want to do (hint: DVD's etc). So what happens if I dd from the block device and also from a file on the mounted FS, where that file overlaps the bnums I dd'ed? Do we get two copies in the page cache? One for the block device access, and one for the file access? Face it. What you ask for is stupid and fundamentally unworkable. Tell me WHY you are completely ignoring my arguments, when I (a) tell you why your way is bad and stupid (and when you ignore the arguments, don't complain when I call you stupid) and (b) I give you alternate ways to do the same thing, except my suggestion is _faster_ and has none of the downside yours has. WHY? Because I like to understand completely all the different options before giving up on any. That in itself is a good enough reason, IMO. Because I've found that when arguing about this kind of stuff, even if the other person asks for something that is wrong or stupid from your own point of view, if you respect their intelligence, then maybe you can together find an alternative solution that solves the underlying problem but does it cleanly. I've been on the other side of this with a friend and colleague. We used to have healthy arguments that lasted all afternoon. He'd ask for something that was unclean and didn't fit into the structure or the philosophy. But I respected his intelligence, skill and his need for a solution. In the end, we'd come up with a better way than either one would have proposed. We had a dialogue. And because your suspend/resume idea isn't really going to help me much. That's because my boot scripts have the notion of personalities (change the boot configuration by asking the user early on in the boot process). If I suspend after I've got XDM running, it's too late. So what I want is a solution that will keep the kernel clean (believe me, I really do want to keep it clean), but gives me a fast boot too. And I believe the solution is out there. We just haven't found it yet. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
Ingo Oeser writes:
On Tue, May 15, 2001 at 08:10:29AM -0700, Linus Torvalds wrote:
and I don't see why we couldn't expose the driver
name for any file descriptor.
Because we dont like to replace:
if (st.device == MAJOR_1)
bla
else if ...
with
if (!strcmp(st.device,driver_1) )
bla
else if ...
?
There is no win doing it this way, because every time we add a
new driver that fits or change the name of one, we need add
support for it.
Now look at how we can already do these things with devfs. Let's say
I've opened /dev/cdroms/cdrom0 and it's sitting on fd=3.
% ls -lF /proc/self/fd/3
lrwx-- 1 root root 64 May 15 13:24 /proc/self/fd/3 -
/dev/ide/host0/bus0/target1/lun0/cd
So, in my application I do:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
}
if (strncmp (buffer, /dev/ide, 8) == 0) do_ide (fd);
else if (strncmp (buffer, /dev/scsi, 9) == 0) do_scsi (fd);
else do_generic (fd);
That's a lot cleaner than relying on magic numbers, IMNSHO.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Alexander Viro writes:
On Tue, 15 May 2001, Richard Gooch wrote:
Alan Cox writes:
len = readlink (/proc/self/3, buffer, buflen);
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
Set by...?
MeLinus. The device name authority (Peter). Whoever. If you want
Peter to bless it, then fine. But the standard is there. Violators
will be persecuted.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: LANANA: To Pending Device Number Registrants
Alan Cox writes:
if (strcmp (buffer + len - 2, cd) != 0) {
fprintf (stderr, Not a CD-ROM! Bugger off.\n);
exit (1);
And on my box cd is the cabbage dicer whoops
Actually, no, because it's guaranteed that a trailing /cd is a
CD-ROM. That's the standard.
And its back to /dev/disc versus /dev/disk. Dont muddle user picked
file names with kernel namespace bindings please.
Even if we have per-device filesystems, we are going to have the same
issue, in one form or another. If we have a /devicetype trailing
component added on, then somewhere it has to report CD-ROM or cd
or Compact Disc.
Regards,
Richard
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
-
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: Getting FS access events
Linus Torvalds writes: > > On Mon, 14 May 2001, Richard Gooch wrote: > > > > Is there some fundamental reason why a buffer cache can't ever be > > fast? > > Yes. > > Or rather, there is a fundamental reason why we must NEVER EVER look at > the buffer cache: it is not coherent with the page cache. > > And keeping it coherent would be _extremely_ expensive. How do we > know? Because we used to do that. Remember the small mindcraft > benchmark? Yup. Double copies all over the place, double lookups, double > everything. > > You could think: "oh, we only need to look up the buffer cache when we > create a new page cache mapping, so..". > > You'd be wrong. We'd need to go the other way too: every time we create a > new buffer cache entry, we'd need to make sure that it isn't mapped > somewhere in the page cache (impossible), or otherwise we'd do the wrong > thing sometimes (ie we might have two dirty copies, and we wouldn't know > _which_ one is valid etc). > > Aliasing is bad. Don't do it. OK, this (combined with the other message) explains why we want to keep away from the buffer cache. Thanks. > You know, the mark of intelligence is realizing when you're making > the same mistake over and over and over again, and not hitting your > head in the wall five hundred times before you understand that it's > not a clever thing to do. But you didn't have to add this. Please note that I asked why not use the buffer cache. I didn't proclaim that it was the ideal solution. I did say what benefits it had, but I didn't assert that the benefits outweighed the disadvantages. > Please show some intelligence. Well, frankly, I think I have. Things are obvious when you know them already. Even if I'm ignorant, I'm not stupid! Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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: LANANA: To Pending Device Number Registrants
Andi Kleen writes: > On Mon, May 14, 2001 at 01:29:51PM -0700, Linus Torvalds wrote: > > Big device numbers are _not_ a solution. I will accept a 32-bit one, but > > no more, and I will _not_ accept a "manage by hand" approach any more. The > > time has long since come to say "No". Which I've done. If you can't make > > it manage the thing automatically with a script, you won't get a hardcoded > > major device number just because you're lazy. > > As far as I can see it just needs a /proc/devices that also outputs > minor ranges with names, and a small program similar to scsidev to > generate nodes in /dev based on that on the fly on early bootup. You can do that with devfs. It provides all this information. If you really don't want to mount devfs over /dev, then mount it elsewhere and just use it as an information source to populate /dev. No need to add more code to the kernel to do it another way. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - 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/
