Re: [gentoo-dev] Re: [gentoo-desktop] X freezing?

[Greg KH]

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@g.o mailing list