FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 03-12-2012, 08:24 AM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

On Sun, Mar 11, 2012 at 05:09:12AM -0400, Walter Dnes wrote:
> This revision makes 2 changes...

> A) The removal of udev is now standard instead of optional. udev-181
> and higher will be pulling in kmod, and anything else that kmod depends
> on. Removing udev will avoid unnecessary cruft on your machine.

> B) Splitting up step 3) into 3a) and 3b) for greater clarity as
> requested in user feedback.

> The usual warnings apply...
> * this is a beta
> * use a spare test machine
> * if you don't follow the instructions correctly, the result might be
> an unbootable linux
> * even if you do follow instructions, the result might be an unbootable
> linux

Yep, I got the (effectively) unbootable machine: My LVM partitions didn't
get mounted. My precaution against it was: (i) Copy my entire (working)
root partition to a new partition. (ii) Edit the first line of the new
/etc/fstab. (iii) Add a new entry to /etc/lilo.conf. It's handy having
a small root partition. :-)

> 1) Set up your kernel to support and automount a devtmpfs filesystem at
> /dev

> * If you prefer to edit .config directly, set
> CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y

> * If you prefer "make menuconfig", the route is as shown below. Note
> that the "Autount devtmpfs..." option won't appear until you enable
> "Maintain a devtmpf..." option.

> make menuconfig
> Device Drivers --->
> Generic Driver Options --->
>[*] Maintain a devtmpfs filesystem to mount at /dev
>[*] Automount devtmpfs at /dev, after the kernel mounted the rootfs

> Once you've made the changes, rebuild the kernel.


> 2) Set up for emerging busybox. busybox requires the "mdev" flag in
> this situation. The "static" flag is probably also a good idea. In
> file /etc/portage/package.use add the line

> sys-apps/busybox static mdev

> Now, "emerge busybox"


> 3 a) Create /sbin/linuxrc containing at least

> #!/bin/busybox ash
> mount -t proc proc /proc
> mount -t sysfs sysfs /sys
> exec /sbin/init

> This should be enough for most users. If you have an unusual setup,
> you may need additional stuff in there. Remember to
> "chmod 744 /sbin/linuxrc" to make it executable.

I may have an unusual setup, but I don't think so. I've got my root
partition as ext2 on /dev/sda5, and everything else under LVM.
Otherwise, pretty standard.

> In the bootloader "append" line, include "init=/sbin/linuxrc". If
> you're using lilo remember to re-run lilo to implement the changes. If
> you're using another bootloader, make the equivalant initialization.

How do I know whether my /sbin/linuxrc actually ran? Maybe, I mean how
can I be sure my "append = "init=/sbin/linuxrc"" actually worked?

> 4) Remove udev from the services list, and replace it with mdev. Type
> the following 2 commands at the command line
> rc-update del udev sysinit
> rc-update add mdev sysinit

Done

> 5) reboot to your new kernel. You're now running without using udev.

Here's where I got problems. None of my LVM partitions got mounted.
Here're a few lines of my bootup messages, just before the problem:

* Setting up mdev as hotplug agent ...
* Populating /dev with existing devices with mdev -s ...
* Mounting /dev/pts ...
* Mounting /dev/shm ...

Enter runlevel: 3
* Setting up system clock using the hardware clock [UTC]
* Setting up the Logical Volume Manager
* Checking local filesystems
/dev/sda5: clean, 6052/655360 files, 180423/2621440 blocks
fsck.ext3: No such file or directory while trying to open /dev/vg/usr
.....
<and so on, for all my other partitions>

> 6) Remove udev as per the following instructions...

> * execute the following command at the commandline
> emerge --unmerge sys-fs/udev

> * In file /atc/portage/package.mask, append the line
> sys-fs/udev
> Create the file if it doesn't already exist. You now have a totally
> udev-free machine

Help would be appreciated.

> --
> Walter Dnes <waltdnes@waltdnes.org>

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-13-2012, 11:33 AM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

Hello, Walter.

On Tue, Mar 13, 2012 at 03:14:55AM -0400, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 09:24:32AM +0000, Alan Mackenzie wrote

> Sorry, mdev is not for you, it looks like udev is a mandatory
> dependancy for lvm2. I tried "emerge -pv lvm2" and it came back with...

> waltdnes@d530 ~ $ emerge -pv lvm2

> These are the packages that would be merged, in order:

> Calculating dependencies... done!

> !!! All ebuilds that could satisfy ">=sys-fs/udev-151-r4" have been masked.
> !!! One of the following masked packages is required to complete your request:
> - sys-fs/udev-9999::gentoo (masked by: package.mask, missing keyword)
> /etc/portage/package.mask:

> I'll update my instructions to mention this. Thanks for your help.
> Even a negative result, i.e. knowing what doesn't work, is one more
> piece of information in my quest.

It seems it's not quite as simple as that. I've looked at it again, and
after booting (unsuccessfuly (without non-root partitions)), the devices
/dev/md-0, /dev/md-1, ........ existed. Also existing was the directory
/dev/mapper, containing devices like /dev/mapper/vg-usr. (They're sort
of symlinks, I think).

When I mounted all of these LVM partitions by hand, my system worked
(modulo the services which had failed to start). So I then modified my
/etc/fstab to use /dev/mapper/vg-usr, and my system came up (almost).
What didn't work was X-Windows - when I started it, the keyboard and
mouse were dead. (Good job the reset button still worked.)

I don't know if booting this way loses any LVM functionality. I haven't
tested that out yet. I suspect it will.

The only other wierd thing was, when I restarted my "working" system,
eth0 was missing. When I rebooted, it was there again.

> --
> Walter Dnes <waltdnes@waltdnes.org>

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-13-2012, 12:05 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

Hi, Walter.

On Tue, Mar 13, 2012 at 03:33:06AM -0400, Walter Dnes wrote:
> On Mon, Mar 12, 2012 at 09:24:32AM +0000, Alan Mackenzie wrote

> Once you're back to your old setup, can you do me a favour? Please do
> the following...

> 1) Add the line...

> sys-fs/udev

> to /etc/portage/package.mask.

DONE.

> 2) Run the 2 commands
> emerge -pv system > system.txt
> emerge -pv world > world.txt

> 3) Remove the "sys-fs/udev" entry from /etc/portage/package.mask.

:-) I would have forgotten about that.

> and gzip or zip the files system.txt and world.txt and file-attach them.
> My guess is that at the end of world.txt, there will be a complaint
> about udev being masked. I intend to add that sanity-check to the
> instructions, so that people will know ahead of time whether or not
> they'll run into this problem.

I also did "2> {system,world}.err". system.err was empty. I've included
world.err in the enclosed tarball.

> Again, sorry about putting you through this trouble. You did what a
> beta tester is supposed to do, i.e. find problems/bugs.

Not at all! I'd love to get this working on my machine.

> --
> Walter Dnes <waltdnes@waltdnes.org>

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-13-2012, 06:47 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

Hello, Walter,

On Tue, Mar 13, 2012 at 03:00:52PM -0400, Walter Dnes wrote:
> On Tue, Mar 13, 2012 at 01:05:34PM +0000, Alan Mackenzie wrote

> > I also did "2> {system,world}.err". system.err was empty. I've included
> > world.err in the enclosed tarball.

> From your error listing, it looks like lvm2, kde, and gnome (including
> the XFCE subset) require udev. Ouch.

:-) This cannot be the case. Otherwise somebody would have said. Hmm.
What we could do with is a "requires xdev", for x in (m u). I've
forgotten what that's called in portage.

There are surely lots of packages marked "need udev" which don't really
need it at all. I mean, are there any programs which need precisely
udev to work, as opposed to a populated /dev?

I mean, what does udev give me that mdev won't? That's not really a
rhetorical question. What potential benefits am I throwing away by
converting to mdev?

> --
> Walter Dnes <waltdnes@waltdnes.org>

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-13-2012, 08:07 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

Hello, Canek,

I thought you'd be replying to me here. :-)

On Tue, Mar 13, 2012 at 02:27:25PM -0600, Canek Peláez Valdés wrote:
> On Tue, Mar 13, 2012 at 1:47 PM, Alan Mackenzie <acm@muc.de> wrote:
> > Hello, Walter,

> > On Tue, Mar 13, 2012 at 03:00:52PM -0400, Walter Dnes wrote:
> >> On Tue, Mar 13, 2012 at 01:05:34PM +0000, Alan Mackenzie wrote

> >> > I also did "2> {system,world}.err". *system.err was empty. *I've included
> >> > world.err in the enclosed tarball.

> >> * From your error listing, it looks like lvm2, kde, and gnome (including
> >> the XFCE subset) require udev. *Ouch.

> > :-) *This cannot be the case. *Otherwise somebody would have said. *Hmm.
> > What we could do with is a "requires xdev", for x in (m u). *I've
> > forgotten what that's called in portage.

> > There are surely lots of packages marked "need udev" which don't really
> > need it at all. *I mean, are there any programs which need precisely
> > udev to work, as opposed to a populated /dev?

> > I mean, what does udev give me that mdev won't? *That's not really a
> > rhetorical question. *What potential benefits am I throwing away by
> > converting to mdev?

> >>From my desktop:

> centurion ~ # equery depends udev
> * These packages depend on udev:
> dev-libs/libatasmart-0.18 (>=sys-fs/udev-143)
> dev-python/python-gudev-147.2 (>=sys-fs/udev-171[gudev])
> (>=sys-fs/udev-147[extras])
> gnome-base/gnome-settings-daemon-3.2.2-r1 (packagekit ? sys-fs/udev[gudev])
> (packagekit ? sys-fs/udev[extras])
> (udev ? sys-fs/udev[gudev])
> (udev ? sys-fs/udev[extras])
> gnome-base/gvfs-1.10.1 (!prefix ? >=sys-fs/udev-164-r2)
> (>=sys-fs/udev-171[gudev])
> (>=sys-fs/udev-145[extras])
> media-gfx/shotwell-0.11.6 (>=sys-fs/udev-171[gudev])
> (>=sys-fs/udev-145[extras])
> media-libs/libcanberra-0.28-r5 (udev ? >=sys-fs/udev-160)
> media-libs/libgpod-0.8.0 (udev ? sys-fs/udev)
> media-libs/mesa-7.11.2 (gbm ? sys-fs/udev)
> media-sound/pulseaudio-1.1-r1 (udev ? >=sys-fs/udev-171[hwdb])
> (udev ? >=sys-fs/udev-143[extras])
> media-sound/rhythmbox-2.95 (>=sys-fs/udev-171[gudev])
> (>=sys-fs/udev-145[extras])
> media-video/cheese-3.2.2 (>=sys-fs/udev-171[gudev])
> (>=sys-fs/udev-145-r1[extras])
> net-im/empathy-3.2.2 (v4l ? sys-fs/udev[gudev])
> (v4l ? sys-fs/udev[extras])
> net-misc/networkmanager-0.9.2.0-r5 (>=sys-fs/udev-171[gudev])
> (>=sys-fs/udev-147[extras])
> net-wireless/bluez-4.98-r2 (>=sys-fs/udev-169)
> net-wireless/gnome-bluetooth-3.2.2 (sys-fs/udev)
> sys-apps/systemd-43-r1 (>=sys-fs/udev-172)
> sys-fs/lvm2-2.02.88 (>=sys-fs/udev-151-r4)
> sys-fs/udisks-1.0.4-r1 (>=sys-fs/udev-171[gudev])
> (>=sys-fs/udev-147[extras])
> sys-kernel/dracut-017-r2 (>=sys-fs/udev-164)
> sys-power/upower-0.9.15 (kernel_linux ? >=sys-fs/udev-171-r1[gudev])
> (kernel_linux ? <sys-fs/udev-171-r1[extras])
> virtual/dev-manager-0 (sys-fs/udev)
> x11-base/xorg-server-1.11.2-r2 (udev ? >=sys-fs/udev-150)
> x11-libs/cairo-1.10.2-r1 (drm ? >=sys-fs/udev-136)
> x11-misc/colord-0.1.15 (udev ? sys-fs/udev[gudev])
> (udev ? sys-fs/udev[extras])

> I don't know exactly what packages actually *require* udev. What I can
> say with some certainty is that more and more "maistream" packages
> will require udev either directly or indirectly (by some dep).

OK. I haven't heard of anybody here with mdev being unable to run an
application. Not yet, anyway.

But I really meant what functionality udev has that mdev lacks. For
example, mdev this morning recognised my USB stick being inserted, and
created /dev/sdc for it.

> You will lose those with mdev.

> "Fringe" programs will not require udev, or it will be optional; but
> the moment a "fringe" program reaches critical mass to become
> "maistream", the probability of it needing udev (directly or
> indirectly) will increase.

> I'm willing to bet a beer on that prediction.

Thanks for the reply.

> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-13-2012, 09:20 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

Hello, Neil.

On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote:
> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote:

> > But I really meant what functionality udev has that mdev lacks. For
> > example, mdev this morning recognised my USB stick being inserted, and
> > created /dev/sdc for it.

> udev does a *lot* more than that, for example the persistent naming of
> network interfaces. More significantly, it can run programs based on
> device rules.

This is where I start getting unhappy. Is there any need for this
blurring? Having device nodes is essential to a linux system, and
some programs use these nodes. Why must they be mashed together into a
tasteless mush? Is there some advantage to this I haven't twigged yet?

> For example, usb_modeswitch installs a udev rule to switch a 3G USB
> modem from CD to modem mode, without which it won't work.

Same question as above: why does that switching have to be done via the
device node system rather than via the driver. Isn't that what drivers
are for?

> That's fine when you plug it into a running system, but when you boot
> with it plugged in, it can trip over itself because the usb_modeswitch
> executable is in /usr/sbin.

Er, that's a different discussion altogether. ;-)

> You could use this to argue that /usr should be mounted before udev is
> started, but you could just as well use it to argue that udev should not
> be trying to run such rules at the boot runlevel.

Or that udev shouldn't have "rules". I still don't understand the basic
concept driving this thing. My HDDs don't need rules - they just need a
mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
drivers built into my kernel.

Am I being stupid? Despite your example above, I still don't see what
udev is about, why it's necessary, or even why it's advantageous.

> --
> Neil Bothwick

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-13-2012, 10:03 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Peláez Valdés wrote:
> On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie <acm@muc.de> wrote:
> > Hello, Neil.

> > On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote:
> >> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote:

> >> > But I really meant what functionality udev has that mdev lacks. *For
> >> > example, mdev this morning recognised my USB stick being inserted, and
> >> > created /dev/sdc for it.

> >> udev does a *lot* more than that, for example the persistent naming of
> >> network interfaces. More significantly, it can run programs based on
> >> device rules.

> > This is where I start getting unhappy. *Is there any need for this
> > blurring? *Having device nodes is essential to a linux system, and
> > some programs use these nodes. *Why must they be mashed together into a
> > tasteless mush? *Is there some advantage to this I haven't twigged yet?

> >> For example, usb_modeswitch installs a udev rule to switch a 3G USB
> >> modem from CD to modem mode, without which it won't work.

> > Same question as above: why does that switching have to be done via the
> > device node system rather than via the driver. *Isn't that what drivers
> > are for?

> >> That's fine when you plug it into a running system, but when you boot
> >> with it plugged in, it can trip over itself because the usb_modeswitch
> >> executable is in /usr/sbin.

> > Er, that's a different discussion altogether. *;-)

> >> You could use this to argue that /usr should be mounted before udev is
> >> started, but you could just as well use it to argue that udev should not
> >> be trying to run such rules at the boot runlevel.

> > Or that udev shouldn't have "rules". *I still don't understand the basic
> > concept driving this thing. *My HDDs don't need rules - they just need a
> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> > drivers built into my kernel.

> > Am I being stupid? *Despite your example above, I still don't see what
> > udev is about, why it's necessary, or even why it's advantageous.

> IMHO, the thing that most people are missing is the fact that neither
> udev nor Linux "got complicated". The computing world itself "got
> complicated".

Not really. It's been getting more complicated since long before I
starting working in it in 1980. Nothing's changed there.

> We have Linux running in the same beige machines it has been running
> since 1991, but it also runs in TVs, tablets, cellphones, fridges,
> cars, ebook readers, and (soon enough, I'm sure) the kitchen sink.
> This devices behave very differently from our old and beloved beige
> boxen.

Not at the level of needing device nodes under /dev and drivers connected
to them, they haven't.

> They need to handle lots of different hardware comming and going, via
> USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future.

Yes. That's why there's a generic facility for building arbitrary
drivers into a kernel. That's not new either.

> The principal idea behind udev, is that we *don't* kown (we *can't*
> know) what hardware this or that machine is gonna have at some point.
> And we want the machine (and the new hardware) to "just work" when
> they are connected.

Huh? What's that to do with udev? You're talking at far too high a
level of abstraction. The new hardware will "just work" if there are the
correct drivers built in. That's as true of udev as it is of mdev as it
is of the old static /dev with mknod.

[ .... ]

> So, yeah, it's more complicated. The world got complicate; better get
> used to it.

You're bluffing, aren't you? You really don't have any more idea than I
do about the technical motivation for udev, do you?

> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-13-2012, 10:43 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

On Tue, Mar 13, 2012 at 11:03:50PM +0000, Neil Bothwick wrote:
> On Tue, 13 Mar 2012 22:20:19 +0000, Alan Mackenzie wrote:

> > > udev does a *lot* more than that, for example the persistent naming of
> > > network interfaces. More significantly, it can run programs based on
> > > device rules.

> > This is where I start getting unhappy. Is there any need for this
> > blurring? Having device nodes is essential to a linux system, and
> > some programs use these nodes. Why must they be mashed together into a
> > tasteless mush? Is there some advantage to this I haven't twigged yet?

> I agree with you on this. The initial creation of device nodes belongs in
> early startup, running arbitrary programs does not.

> > > For example, usb_modeswitch installs a udev rule to switch a 3G USB
> > > modem from CD to modem mode, without which it won't work.

> > Same question as above: why does that switching have to be done via the
> > device node system rather than via the driver. Isn't that what drivers
> > are for?

> udev is not a device node system, it is a device manager. Requiring
> drivers to handle it gets us into the same mess as Windows, where each
> driver has to implement the same functionality itself. If a new modem is
> released with a different USB ID, but using the same driver, your way
> would require a new kernel, the current approach requires one line to be
> added to a config file.

Right! Now this is beginning to look like a beginning of an answer to my
lack of understanding. ;-)

This config file - is this the udev "rules"? Or am I getting mixed up
with something else?

> > > That's fine when you plug it into a running system, but when you boot
> > > with it plugged in, it can trip over itself because the usb_modeswitch
> > > executable is in /usr/sbin.

> > Er, that's a different discussion altogether. ;-)

> How so? It's central to the whole "when do we need /usr?" debate.

I meant we'd already had a wide ranging discussion about early /usr.

> > > You could use this to argue that /usr should be mounted before udev is
> > > started, but you could just as well use it to argue that udev should
> > > not be trying to run such rules at the boot runlevel.

> > Or that udev shouldn't have "rules". I still don't understand the basic
> > concept driving this thing. My HDDs don't need rules - they just need a
> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> > drivers built into my kernel.

> "I don't need it so no one needs it". It sounds like what you need is
> mdev, but many people want or need more from a device manager. There are
> many more and varied devices than simple hard disks.

That's not fair. I'm convinced _I_ don't need more than mdev; I'm still
trying to get a handle on why other devices need more.

> > Am I being stupid? Despite your example above, I still don't see what
> > udev is about, why it's necessary, or even why it's advantageous.

> What you don't see is why *you* need it, and that's fair enough. Just
> consider that it does things that others need, even if you don't.

I'm not trying to be combative. In fact, I'm trying not to be combative.
I'm just trying to get some sort of grasp on what it is I don't yet see.
I want to understand what udev offers that mdev can't, and I'm getting
very frustrated about not being able to find the right questions to ask.

> But I still think the requirement for /usr to be mounted is a lazy, if
> understandable, solution to the way udev's operations are implemented.
> After all, the vast majority of PC Linux installations out there already
> use an initramfs.

They do, and I understand that one - it is the necessity to have a
one-size-fits-all kernel in a binary distribution. As gentooers, we
don't suffer that constraint, therefore we don't (and shouldn't) need an
initramfs, unless we want one.

Anyhow, it's now European bed time, one hour more for me than for you, so
thanks for the discussion and let's call it quits for today. :-)

> --
> Neil Bothwick

> How do I set my laser printer to stun?

How about a picture of Marilyn Monroe?

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-14-2012, 02:16 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

Hello, Canek

On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote:
> On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <acm@muc.de> wrote:

> >*The new hardware will "just work" if there are the correct drivers
> >built in. *That's as true of udev as it is of mdev as it is of the old
> >static /dev with mknod.

> No, it is not. You are letting out the sine qua non of the matter: the
> device has to be built, *and the /dev file should exists*. I hope you
> are not suggesting that we put *ALL* the possible files under /dev,
> because that was the idea before devfs, and it doesn't work *IN
> GENERAL*.

Previously you made appropriate /dev entries with mknod, giving the
device major and minor numbers as parameters. This appeared to work in
general - I'm not aware of any device it didn't work for.

> So, you need something to handle device files on /dev, so you don't
> need every possible device file for every possible piece of hardware.
> But then you want to handle the same device with the same device name,
> so you need some kind of database. Then for the majority of users,
> they want to see *something* happen when they connect aa piece of
> hardware to their computers.

That happened under the old static /dev system. What was that /dev
system, if not a database matching /dev names to device numbers? I'm not
sure what you mean by "same device" and "same device name".

> So you need to handle the events associated with the connections (or
> discovery, for things like Bluetooth) of the devices, and since udev is
> already handling the database and the detection of
> connections/discovery, I agree with the decision of leting udev to
> execute programs when something gets connected. You could get that
> function in another program, but you are only moving the problem, *and
> it can also happen very early at boot time*, so lets udev handle it all
> the time.

Early in boot time, you only need things like disk drives, graphic cards
and keyboards. Anything else can be postponed till late boot time.

> I hope you see where I'm going. As I said before, mdev could (in
> theory) do the same that udev does. But then it will be as complicated
> as udev, *because it is a complicated problem* in general. And I again
> use my fuel injection analogy: it is not *necessary*. It is just very
> damn convenient.

It may be a complicated problem in general, but many people do not need
that generality. I suspect the vast majority don't need it. Neither the
typical desktop, the typical server, nor typical embedded devices like
routers.

> I have a really time understanding why you don't see the complexity on
> the problem. I explained above: it is a complicated problem (when
> dealing with the general case), and therefore the (general) solution is
> bound to be also complicated.

I've had a hard time understanding, because up till now, nobody's
described the problem in detail - there's only been hand-waving.

> You want it simple? Tha'ts fine, it is possible. It's just that it
> will not solve the general problem, just a very specific subset of it.

That subset used by the vast majority of Linux users. And yes, I do want
it simple, because elegant simplicity is the best way, IMAO. You, on the
other hand, seem to love complicated solutions because they are "the way
forward". We'll have to agree to disagree on this one.

> Just as mdev is doing; Walt just posted an email explaining that if
> you use GNOME, KDE, XFCE, or LVM2, mdev is not for you.

Walter is, I believe, mistaken here. I can mount and use my LVM2
partitions. Gnome looks like it comes up OK, but that could be moot,
since right now I haven't got keyboard/mouse drivers under the X server.

> I will not be surprised if in the future the list of programs "not for
> mdev" only grows.

There's a difference between "needed by portage" and "doesn't work under
mdev". As I say, it will all be moot if the evdev driver won't work
under mdev.

> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México

--
Alan Mackenzie (Nuremberg, Germany).
 
Old 03-14-2012, 06:59 PM
Alan Mackenzie
 
Default Beta test Gentoo with mdev instead of udev; version 5 - failu-(

Good evening, Stroller.

On Wed, Mar 14, 2012 at 05:56:34PM +0000, Stroller wrote:

> On 13 March 2012, at 22:20, Alan Mackenzie wrote:
> > …
> >> udev does a *lot* more than that, for example the persistent naming of
> >> network interfaces. More significantly, it can run programs based on
> >> device rules.

> > This is where I start getting unhappy. Is there any need for this
> > blurring? Having device nodes is essential to a linux system, and
> > some programs use these nodes. Why must they be mashed together into a
> > tasteless mush? Is there some advantage to this I haven't twigged yet?

> Ok, so my system has 2 network cards. Maybe I only use one of them, or
> maybe they need to be physically connected in a certain way (one to
> LAN, the other WAN).

> Before asking this question, with the knowledge and understanding that
> we all already have, don't you have to first have to explain how you're
> going to ensure that eth0 is always assigned by the system to the first
> NIC and eth1 always to the second NIC?

By kernel parameters? I once had a problem with the kernel not finding
my hard drives. I solved it by putting the following kernel parameters
into my lilo.conf:

ide2=0xd000,0xd402,11 ide3=0xd800,0xdc02,11

The same could be done for network cards.

> >> You could use this to argue that /usr should be mounted before udev is
> >> started, but you could just as well use it to argue that udev should not
> >> be trying to run such rules at the boot runlevel.

> > Or that udev shouldn't have "rules". I still don't understand the basic
> > concept driving this thing. My HDDs don't need rules - they just need a
> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> > drivers built into my kernel.

> I'm assuming, then, that you're happy opening a terminal and typing
> `mkdir /mnt/diskname` and mounting the device every time you plug a new
> disk in?

You might be taking me just a wee bit _too_ literally there. But yes, I
mount each removable device I plug in.

> Wouldn't it just be nice to plug in your USB devices - hard-drives and
> flash drives - and have them magically appear on the desktop like they
> do on every other desktop operating system?

Yes.

> Stroller.

--
Alan Mackenzie (Nuremberg, Germany).
 

Thread Tools




All times are GMT. The time now is 11:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org