Mailing List Archive

On Thursday 28 October 2004 1:53 am, you wrote:
> Are they sysfs design flaws or udev design flaws. The reason I ask, is
> that a bunch of kernel developers were talking about rewriting the
> current hotplug/udev system.

sysfs works great. I use it regardless of udev. The main problem is that udev
defeats the entire purpose of modules. Using udev, you must preload any
modules you want to use manually. If you do that, you might as well compile
them into your kernel. I'd much rather not have the driver for any of my
devices loaded until I actually need them.

> But they would still be using sysfs. Also I am curious as to what "new" USB
> Mass Storage driver you are referring to? The current mainstream kernel's
> driver was updated about 4 months ago, and still presents itself as a low
> level scsi driver to the kernel (meaning it needs scsi.ko and sd.ko)

Well, I noticed they were suddenly "udX" when I moved to 2.6.9... Now that I
think of it, I'm not sure I tested 2.6.9 w/o udev, so it might have been a
udev naming thing that I just assumed meant the device was a USB disk (w/o
emulation)... Either way, it didn't work very well for me (e.g. I couldn't
use my IDE->USB adaptor).

>
> > -----Original Message-----
> > From: Luke-Jr [mailto:luke-jr@utopios.org]
> > Sent: Wednesday, October 27, 2004 8:06 PM
> > To: Stuart Stegall
> > Subject: Re: [gentoo-desktop] X freezing?
> >
> > On Wednesday 27 October 2004 11:17 pm, you wrote:
> > > What kind of problems have you experienced? Since 2.6.7 and
> >
> > onward, I
> >
> > > have had 0 problems of any kind. Currently I am running 2.6.10rc1
> > > myself. (10 out of 340 servers in my apache rotation are as well)
> >
> > In particular, the new USB Mass Storage drivers (formerly,
> > SCSI emulation was
> > used) caused nothing but problems... Perhaps not a big issue
> > by itself, but I
> > had been switching to udev (from devfs) at the same time, so
> > that made it
> > seem much worse.
> > Regarding udev, needless to say I'm back to devfs... udev
> > just has too many
> > design flaws to counter the few benefits.
> >
> > > > -----Original Message-----
> > > > From: Luke-Jr [mailto:luke-jr@utopios.org]
> > > > Sent: Wednesday, October 27, 2004 11:32 AM
> > > > To: gentoo-desktop@lists.gentoo.org
> > > > Subject: Re: [gentoo-desktop] X freezing?
> > > >
> > > > On Wednesday 27 October 2004 2:45 pm, Soos Istvan wrote:
> > > > > > And if you do not have a NForce2 or 3 chipset, then
> > > >
> > > > please don't use
> > > >
> > > > > > the kernel agpgart with ati-drivers, as I have never gotten
> > > > > > stability with ati-drivers and external agpgart.
> > > > >
> > > > > It is stable now. :) (2.6.9 kernel agpgart, 3.14.1
> > > >
> > > > ati-drivers, 6.7.0
> > > >
> > > > > xorg-x11, SiS Chipset, 3D accelleration works perfect)
> > > >
> > > > eck... had nothing but problems w/ 2.6.9
> > > > --
> > > > Luke-Jr
> > > > Developer, Utopios
> > > > http://utopios.org/
> > > >
> > > > --
> > > > gentoo-desktop@gentoo.org mailing list
> >
> > --
> > Luke-Jr
> > Developer, Utopios
> > http://utopios.org/

--
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-dev@gentoo.org mailing list

wwwwwwwwwwwwwwwhy oh whyyyyyyyyyyyyyyyyy do you keep responding to gentoo-dev
instead of gentoo-desktop
-mike

--
gentoo-dev@gentoo.org mailing list

On Wed October 27 2004 22:11, Mike Frysinger wrote:
> wwwwwwwwwwwwwwwhy oh whyyyyyyyyyyyyyyyyy do you keep responding to
> gentoo-dev instead of gentoo-desktop
> -mike

Because he's using Kmail, and he's got two or more lists going to the same
folder, but he has the folder configured for gentoo-dev, so when he hits
list-reply (L), it sends it to gentoo-dev, not the mailing list it's
supposed to go to.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

[.yeah, it went to the wrong list, but I might as well address the issues
involved...]

On Thu, Oct 28, 2004 at 02:05:37AM +0000, Luke-Jr wrote:
> On Thursday 28 October 2004 1:53 am, you wrote:
> > Are they sysfs design flaws or udev design flaws. The reason I ask, is
> > that a bunch of kernel developers were talking about rewriting the
> > current hotplug/udev system.

No we were not.

> sysfs works great. I use it regardless of udev. The main problem is that udev
> defeats the entire purpose of modules. Using udev, you must preload any
> modules you want to use manually. If you do that, you might as well compile
> them into your kernel. I'd much rather not have the driver for any of my
> devices loaded until I actually need them.

See the udev FAQ for the answers to this question. In short, no, udev
does NOT "defeat the entire purpose of modules." Geesh, where do people
get ideas like this from...

> > But they would still be using sysfs. Also I am curious as to what "new" USB
> > Mass Storage driver you are referring to? The current mainstream kernel's
> > driver was updated about 4 months ago, and still presents itself as a low
> > level scsi driver to the kernel (meaning it needs scsi.ko and sd.ko)
>
> Well, I noticed they were suddenly "udX" when I moved to 2.6.9...

"ubX", not "udX". And that happened because you selected the block UB
driver. So you asked the kernel to do this, nothing "sudden" about it
at all.

> Now that I think of it, I'm not sure I tested 2.6.9 w/o udev, so it
> might have been a udev naming thing that I just assumed meant the
> device was a USB disk (w/o emulation)... Either way, it didn't work
> very well for me (e.g. I couldn't use my IDE->USB adaptor).

Stick with the usb-storage driver if you don't like the ub driver. It's
not for everyone (as the documentation for the driver states.)

Good luck,

greg k-h

--
gentoo-dev@gentoo.org mailing list

On Thursday 28 October 2004 2:50 pm, you wrote:
> [.yeah, it went to the wrong list, but I might as well address the issues
> involved...]

How is -dev any less appropriate for this than -desktop?

>
> On Thu, Oct 28, 2004 at 02:05:37AM +0000, Luke-Jr wrote:
> > On Thursday 28 October 2004 1:53 am, you wrote:
> > > Are they sysfs design flaws or udev design flaws. The reason I ask, is
> > > that a bunch of kernel developers were talking about rewriting the
> > > current hotplug/udev system.
>
> No we were not.

I think he meant some Linux kernel developers, not neccesarilly Gentoo, though
I'm not on LKML or any such lists personally.

>
> > sysfs works great. I use it regardless of udev. The main problem is that
> > udev defeats the entire purpose of modules. Using udev, you must preload
> > any modules you want to use manually. If you do that, you might as well
> > compile them into your kernel. I'd much rather not have the driver for
> > any of my devices loaded until I actually need them.
>
> See the udev FAQ for the answers to this question. In short, no, udev
> does NOT "defeat the entire purpose of modules." Geesh, where do people
> get ideas like this from...

>From udev FAQ:
>Q: But udev will not automatically load a driver if a /dev node is opened
>when it is not present like devfs will do.
>A: If you really require this functionality, then use devfs. It is still
>present in the kernel."

In short, the "solution" to that problem according to the udev FAQ is to not
use udev.

>Q: Oh come on, pretty please. It can't be that hard to do.
>A: Such a functionality isn't needed on a properly configured system. All
> devices present on the system should generate hotplug events, loading
> the appropriate driver, and udev will notice and create the
> appropriate device node. If you don't want to keep all drivers for your
> hardware in memory, then use something else to manage your modules
> (scripts, modules.conf, etc.) This is not a task for udev.

What makes you think I want the drivers loaded just because the device is
connected/available? It may be insignificantly small, but I don't see a
reason to use the RAM neccesary nor decrease the stability of my systems for
something I'm not using.
For example, my motherboard has a parallel port, but I don't want the driver
loaded unless I'm actually using it (which is fairly rare).

>
> > > But they would still be using sysfs. Also I am curious as to what
> > > "new" USB Mass Storage driver you are referring to? The current
> > > mainstream kernel's driver was updated about 4 months ago, and still
> > > presents itself as a low level scsi driver to the kernel (meaning it
> > > needs scsi.ko and sd.ko)
> >
> > Well, I noticed they were suddenly "udX" when I moved to 2.6.9...
>
> "ubX", not "udX". And that happened because you selected the block UB
> driver. So you asked the kernel to do this, nothing "sudden" about it
> at all.

>From kernel configuration:
>Low Performance USB Block driver (BLK_DEV_UB)
>
>This driver supports certain USB attached storage devices
>such as flash keys.

It was newly available and the description implies that it is a desirable
option.

>
> > Now that I think of it, I'm not sure I tested 2.6.9 w/o udev, so it
> > might have been a udev naming thing that I just assumed meant the
> > device was a USB disk (w/o emulation)... Either way, it didn't work
> > very well for me (e.g. I couldn't use my IDE->USB adaptor).
>
> Stick with the usb-storage driver if you don't like the ub driver. It's
> not for everyone (as the documentation for the driver states.)

Usually, stuff that doesn't work is marked EXPERIMENTAL or such. Nothing to
suggest that in the summary. Using a bunch of greps on the Documentation
directory, there does not seem to be additional documentation for the ub
stuff. Where does it state that it shouldn't be used (outside of the default
N)?
--
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-dev@gentoo.org mailing list

Luke-Jr wrote:
> On Thursday 28 October 2004 2:50 pm, you wrote:
>
>>[.yeah, it went to the wrong list, but I might as well address the issues
>>involved...]
>
>
> How is -dev any less appropriate for this than -desktop?
>

Well, seeing as -dev is for discussion involving the development of the
gentoo distribution, and -desktop is for discussion of exactly this sort
of thing, this topic is definitely inappropriate for -dev. Therefore,
this thread should end on -dev and continue on -desktop.

Steve

--
gentoo-dev@gentoo.org mailing list

On Thu, Oct 28, 2004 at 04:16:14PM +0000, Luke-Jr wrote:
> > On Thu, Oct 28, 2004 at 02:05:37AM +0000, Luke-Jr wrote:
> > > On Thursday 28 October 2004 1:53 am, you wrote:
> > > > Are they sysfs design flaws or udev design flaws. The reason I ask, is
> > > > that a bunch of kernel developers were talking about rewriting the
> > > > current hotplug/udev system.
> >
> > No we were not.
>
> I think he meant some Linux kernel developers, not neccesarilly Gentoo, though
> I'm not on LKML or any such lists personally.

Heh, I meant "we" as in "we kernel developers", myself included...

> > > sysfs works great. I use it regardless of udev. The main problem is that
> > > udev defeats the entire purpose of modules. Using udev, you must preload
> > > any modules you want to use manually. If you do that, you might as well
> > > compile them into your kernel. I'd much rather not have the driver for
> > > any of my devices loaded until I actually need them.
> >
> > See the udev FAQ for the answers to this question. In short, no, udev
> > does NOT "defeat the entire purpose of modules." Geesh, where do people
> > get ideas like this from...
>
> >From udev FAQ:
> >Q: But udev will not automatically load a driver if a /dev node is opened
> >when it is not present like devfs will do.
> >A: If you really require this functionality, then use devfs. It is still
> >present in the kernel."
>
> In short, the "solution" to that problem according to the udev FAQ is to not
> use udev.

If you want to rely on such a broken, antiquated system, sure, don't use
udev.

> >Q: Oh come on, pretty please. It can't be that hard to do.
> >A: Such a functionality isn't needed on a properly configured system. All
> > devices present on the system should generate hotplug events, loading
> > the appropriate driver, and udev will notice and create the
> > appropriate device node. If you don't want to keep all drivers for your
> > hardware in memory, then use something else to manage your modules
> > (scripts, modules.conf, etc.) This is not a task for udev.
>
> What makes you think I want the drivers loaded just because the device is
> connected/available? It may be insignificantly small, but I don't see a
> reason to use the RAM neccesary nor decrease the stability of my systems for
> something I'm not using.
> For example, my motherboard has a parallel port, but I don't want the driver
> loaded unless I'm actually using it (which is fairly rare).

Great, then have a "load lp module" script that you run to load the
driver. Don't rely on accessing the device node to load a module for
you. It's just wrong, and is not the way the Linux kernel has been
evolving over the past 4 years. See my posts on lkml for more details,
I'm not going to go into it again here.

> > > > But they would still be using sysfs. Also I am curious as to what
> > > > "new" USB Mass Storage driver you are referring to? The current
> > > > mainstream kernel's driver was updated about 4 months ago, and still
> > > > presents itself as a low level scsi driver to the kernel (meaning it
> > > > needs scsi.ko and sd.ko)
> > >
> > > Well, I noticed they were suddenly "udX" when I moved to 2.6.9...
> >
> > "ubX", not "udX". And that happened because you selected the block UB
> > driver. So you asked the kernel to do this, nothing "sudden" about it
> > at all.
>
> >From kernel configuration:
> >Low Performance USB Block driver (BLK_DEV_UB)
> >
> >This driver supports certain USB attached storage devices
> >such as flash keys.
>
> It was newly available and the description implies that it is a desirable
> option.

"Low Performance" is a desirable option? "flash keys" for your
IDE/SCSI/USB bridge device? Yeah, I admit the documentation isn't the
best, but it should work for your device, but be slow. If you don't
like it, don't select it to be built.

> > > Now that I think of it, I'm not sure I tested 2.6.9 w/o udev, so it
> > > might have been a udev naming thing that I just assumed meant the
> > > device was a USB disk (w/o emulation)... Either way, it didn't work
> > > very well for me (e.g. I couldn't use my IDE->USB adaptor).
> >
> > Stick with the usb-storage driver if you don't like the ub driver. It's
> > not for everyone (as the documentation for the driver states.)
>
> Usually, stuff that doesn't work is marked EXPERIMENTAL or such. Nothing to
> suggest that in the summary.

It isn't EXPERIMENTAL. It works just fine for me on a whole lot of USB
devices. Pete has done a wonderful job on the driver. And if you have
any problems that might be caused by it, please let him know so he can
fix it. If he doesn't know, how do you expect it to be fixed. Please
file bugs at bugzilla.kernel.org for stuff like this, or use email to
the kernel developers.

thanks,

greg k-h

--
gentoo-dev@gentoo.org mailing list

On Thursday 28 October 2004 5:24 pm, Greg KH wrote:
> On Thu, Oct 28, 2004 at 04:16:14PM +0000, Luke-Jr wrote:
> > > On Thu, Oct 28, 2004 at 02:05:37AM +0000, Luke-Jr wrote:
> > > > On Thursday 28 October 2004 1:53 am, you wrote:
> > > > sysfs works great. I use it regardless of udev. The main problem is
> > > > that udev defeats the entire purpose of modules. Using udev, you must
> > > > preload any modules you want to use manually. If you do that, you
> > > > might as well compile them into your kernel. I'd much rather not have
> > > > the driver for any of my devices loaded until I actually need them.
> > >
> > > See the udev FAQ for the answers to this question. In short, no, udev
> > > does NOT "defeat the entire purpose of modules." Geesh, where do
> > > people get ideas like this from...
> > >
> > >From udev FAQ:
> > >Q: But udev will not automatically load a driver if a /dev node is
> > > opened when it is not present like devfs will do.
> > >A: If you really require this functionality, then use devfs. It is
> > > still present in the kernel."
> >
> > In short, the "solution" to that problem according to the udev FAQ is to
> > not use udev.
>
> If you want to rely on such a broken, antiquated system, sure, don't use
> udev.

At least it does what is neccesary, even if it is broken. If udev lacks the
neccesarily functionality, it doesn't matter that it works.

>
> > >Q: Oh come on, pretty please. It can't be that hard to do.
> > >A: Such a functionality isn't needed on a properly configured system.
> > > All devices present on the system should generate hotplug events,
> > > loading the appropriate driver, and udev will notice and create the
> > > appropriate device node. If you don't want to keep all drivers for
> > > your hardware in memory, then use something else to manage your modules
> > > (scripts, modules.conf, etc.) This is not a task for udev.
> >
> > What makes you think I want the drivers loaded just because the device is
> > connected/available? It may be insignificantly small, but I don't see a
> > reason to use the RAM neccesary nor decrease the stability of my systems
> > for something I'm not using.
> > For example, my motherboard has a parallel port, but I don't want the
> > driver loaded unless I'm actually using it (which is fairly rare).
>
> Great, then have a "load lp module" script that you run to load the
> driver.

Nor do I wish to be aware of software using it.

> Don't rely on accessing the device node to load a module for you.

Why not? Makes perfect sense.

> It's just wrong, and is not the way the Linux kernel has been evolving over
> the past 4 years.

How do you figure this? Linux has done automatic module loading for quite a
while, even before devfs. Even if udev simply created the device nodes for
unloaded modules, it would still work.

> > > > > But they would still be using sysfs. Also I am curious as to what
> > > > > "new" USB Mass Storage driver you are referring to? The current
> > > > > mainstream kernel's driver was updated about 4 months ago, and
> > > > > still presents itself as a low level scsi driver to the kernel
> > > > > (meaning it needs scsi.ko and sd.ko)
> > > >
> > > > Well, I noticed they were suddenly "udX" when I moved to 2.6.9...
> > >
> > > "ubX", not "udX". And that happened because you selected the block UB
> > > driver. So you asked the kernel to do this, nothing "sudden" about it
> > > at all.
> > >
> > >From kernel configuration:
> > >Low Performance USB Block driver (BLK_DEV_UB)
> > >
> > >This driver supports certain USB attached storage devices
> > >such as flash keys.
> >
> > It was newly available and the description implies that it is a desirable
> > option.
>
> "Low Performance" is a desirable option? "flash keys" for your
> IDE/SCSI/USB bridge device?

I also use Flash keys. I had no intention of using this module for the bridge,
but for those.
--
Luke-Jr
Developer, Utopios
http://utopios.org/

--
gentoo-dev@gentoo.org mailing list