Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, 20 Mar 2012 01:33:30 +0200, Alan McKinnon wrote: If I don't have £100 to spare, it's probably because I've already spent it on shiny for me :) You don't have an 'undred quid to buy shiny for your missus? Well, I buy lady-shiny for her, but that's completely different. And you've got 10 years on me by my reckoning, so odds are good your missus has been your missus for 30 odd years Ten years, you cheeky whippersnapper! I'm 55. How'd you manage to make it to 30 years without knowing the value of an 'undred quid to buy shiny for your missus? Maybe that's why we were together for 19 years before she married me... -- Neil Bothwick Megabyte: (n.) more than you can comprehend and less than you'll need. signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
Daddy da...@happypenguincomputers.com wrote: On March 11, 2012 at 5:09 AM Walter Dnes waltd...@waltdnes.org 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 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 -- Walter Dnes waltd...@waltdnes.org Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. OK, I am not seeing mdev in the portage tree -- I would like to learn more about this before I take the plunge. So where do I get it and does it create the appropriate device nodes, etc? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On 2012-03-20 20:49, cov...@ccs.covici.com wrote: OK, I am not seeing mdev in the portage tree -- I would like to learn more about this before I take the plunge. So where do I get it and does it create the appropriate device nodes, etc? mdev is part of sys-apps/busybox. See: https://wiki.gentoo.org/wiki/Mdev Best regards Peter K
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Mar 21, 2012 2:52 AM, cov...@ccs.covici.com wrote: Daddy da...@happypenguincomputers.com wrote: On March 11, 2012 at 5:09 AM Walter Dnes waltd...@waltdnes.org 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 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 -- Walter Dnes waltd...@waltdnes.org Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. OK, I am not seeing mdev in the portage tree -- I would like to learn more about this before I take the plunge. So where do I get it and does it create the appropriate device nodes, etc? The creation of device nodes mostly are done by the devtmpfs of the kernel. I recommend the linuxrc to look like this : #!/bin/busybox ash mount -t proc proc /proc mount -t sysfs sysfs /sys echo /bin/mdev /proc/sys/kernel/hotplug /bin/mdev -s exec /sbin/init Before booting, ensure /bin/mdev exists and is a symlink to /bin/busybox. The rest, just follow the steps outlined by waltdnes Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Sat, 17 Mar 2012 16:11:58 +0200, Alan McKinnon wrote: Why not connect that TV? ;) Because the hardware to do so would cost around £100, USB sticks cost rather less :P The hardware is more shiny than the USB stick. Go on, do it. You know you want to. If I had £100 to spend on shiny, I'd spend it on shiny for me. If I don't have £100 to spare, it's probably because I've already spent it on shiny for me :) -- Neil Bothwick I've got a mind like a... a... what's that thing called? signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mon, 19 Mar 2012 23:23:51 + Neil Bothwick n...@digimed.co.uk wrote: On Sat, 17 Mar 2012 16:11:58 +0200, Alan McKinnon wrote: Why not connect that TV? ;) Because the hardware to do so would cost around £100, USB sticks cost rather less :P The hardware is more shiny than the USB stick. Go on, do it. You know you want to. If I had £100 to spend on shiny, I'd spend it on shiny for me. If I don't have £100 to spare, it's probably because I've already spent it on shiny for me :) You don't have an 'undred quid to buy shiny for your missus? And you've got 10 years on me by my reckoning, so odds are good your missus has been your missus for 30 odd years How'd you manage to make it to 30 years without knowing the value of an 'undred quid to buy shiny for your missus? -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Stroller strol...@stellar.eclipse.co.uk writes: 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). In this particular case, it is pity that it is not more deterministic in the first place. When installing a new system, it is not unknown for the ethernet devices not to be enumerated in the same order when booted from install CD and installed system. This can cause problems when doing a remote server install, where you set /etc/conf.d/net according to how the network is plugged during the install, and then when initially booting the installed system the networking does not work because the network port allocation has changed.
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Fri, 16 Mar 2012 22:33:55 + Neil Bothwick n...@digimed.co.uk wrote: I also have a rule on a headless media server to run a script that mounts a USB stick, copies files to it, unmounts it and lets me know when it is done. I can mark files for copying at any time and my wife can just plug in a stick when she wants to copy them for viewing on a small, non-connected TV by her treadmill (her treadmill, I emphasise - I find a keyboard and trackball give me all the exercise I want). Why not connect that TV? ;) Because the hardware to do so would cost around £100, USB sticks cost rather less :P The hardware is more shiny than the USB stick. Go on, do it. You know you want to. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Fri, 16 Mar 2012 22:27:02 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Fri, Mar 16, 2012 at 10:20 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 14, 2012 at 1:22 PM Canek Peláez Valdés can...@gmail.com wrote: Alan, the vast majority of Linux users right now are phone users. At least, that's how I see it. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. Right now Linux runs in my phone, my TV's, my routers and every computer I own. I have a couple of Windows installations, which I use once or twice every three months (I ported a PyGTK program to Windows last week, so I had to boot into Windows for the first time this year). I want Linux running on *everything*, and what is more: I don't want android in my handhelds, I want the full GNOME experience. Regards. -- What phone do you have running which Linux? I'm curious because a couple months ago we got new Samsung Galaxy S phones. I'd previously used an iPhone 3GS for a bit over a year. Since I can't stand Apple, as a company, it was with great joy that we could get 2 of these Galaxy S phones for free (with the 2-year contract, of course). Sony XPeria Play, with Android 2.3.3, I believe. Android != Linux (in context of userspace) To get a phone shipped with a running Linux (in the usual definition of Linux, not Richard Stallman's) you need that Nokia one that will never again see the light of day. Or root your Sony and stick Debian on it. Being a Sony device, that might be hard. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On March 17, 2012 at 10:20 AM Alan McKinnon alan.mckin...@gmail.com
wrote:
Android != Linux (in context of userspace)
To get a phone shipped with a running Linux (in the usual definition of
Linux, not Richard Stallman's) you need that Nokia one that will never
again see the light of day.
Or root your Sony and stick Debian on it. Being a Sony device, that
might be hard.
--
Alan McKinnnon
alan.mckin...@gmail.com
I could also say, IMHO, Ubuntu != Linux (in context of userspace) :-)}
My personal definition of Linux is The Linux Kernel, which source can
be downloaded from kernel.org.
My Samsung Galaxy S has Kernel version 2.6.35.7, which I assume to be The
Linux Kernel.
Sure, it's not beyond Google to steal, or borrow, code and rewrite enough
stuff and call it it's own. But we all know the source. (And failure to
agree to the new Google {Play,Music,Books} and YouTube license(s) has
caused me not to be able to upgrade applications ... 16 iirc and counting.)
I'm just wondering what Linux phone he, or anyone, is using -- after him
saying [the vast majority of Linux users right now are phone users.]
Maybe the vast majority of Linux users are phone users, but I took it to
mean the vast majority of Linux users are those using phones running Linux
(which I highly doubt).
After using the previously mentioned iPhone (my first smartphone) for 1
year, it just made me feel weird being so not-like-Linux. But it works
well, except for decreased cell signal when holding the phone.
After using this Android phone for 3 months, I'm counting the days until I
can upgrade to an iPhone. The Galaxy has frozen, crashed, hung; it's
wireless signal is not nearly as good as the iPhone, nor is it's battery
usage. It has features which I like over the iPhone 3 series, but I've
never used a 4 series to compare. And customer services says, Maybe you
have a virus. We're not trained on Android, just Windoze and Apple
devices. (So why offer them to your customers? There's money in it,
silly!)
Just curious about phones. After using these 2 smartphones (since June
2010), I miss my dumb flip phone. If money were no object, I'd buy one of
the new iPads for ultra portable internet access, and get a simple dumb
phone for cellular use.
--
Happy Penguin Computers`)
126 Fenco Drive( \
Tupelo, MS 38801^^
662-269-2706; 662-491-8613
support at happypenguincomputers dot com
http://www.happypenguincomputers.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wednesday, March 14, 2012 03:41:01 PM Michael Mol wrote: On Wed, Mar 14, 2012 at 2:45 PM, Canek Peláez Valdés can...@gmail.com wrote: Snipped Again, read about devfs. Tighly coupling is the path the developers (in general) are taking. I agree with them. I remember devfs. Never wound up using it, myself, but I followed the drama via kerneltrap and diff -u. There is no such thing as a one-size-fits-all solution, but that's not something you seem to grasp yet. devfs started as a decent tool, actually. It always worked on my desktop. It only stopped working when it was taken out of the kernel and got replaced. Or am I the only one who didn't notice any obvious problems? ;) -- Joost
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wednesday, March 14, 2012 10:59:30 PM Pandu Poluan wrote:
On Mar 14, 2012 10:30 PM, Michael Mol mike...@gmail.com wrote:
On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl tansta...@libertytrek.org
wrote:
Or asked another way -
Why is LVM2 incapable od using mdev?
Alan has explained that LVM2 actually is able to run under mdev, and he's
investigating if there's any LVM2 feature that is not available.
So far, there's none, and I'm strongly suspicious that it's a case of
missing dev symlinks that prevented LVM2 to work; something later on the
default runlevel then created the proper dev entries that allow LVM2 to
work.
If that is the case -- which I strongly suspect -- then one can use mdev's
built-in ability to rename/move a device + create a symlink [1]
[1]
https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/md
ev.txt
I don't have the time to test this yet, but I am definitely planning on trying
mdev. Especially because I don't like the direction udev is going.
Auto-creation of /dev entries. Yes, very usefull
Renaming devices according to some simple rules. Yes, very usefull.
Auto-starting programs when a device is added. Great, when are we getting
autostart support for CDs and USB-keys and under which user-account will
these be executed?
This system is mostly used by me, but my wife also uses it sometimes. Even
when I leave a desktop-session active. She simply starts a second one.
If this is implemented, will the autostart-script run under my account, my
wifes, or *shudder* as root?
Walt, keep up the good work. I need LVM to work on the server, once we have
confirmed it does work and how to configure mdev to work with it, I'll start
to switch my servers.
The presumption is that lvm's dependent binaries would be found
somewhere under a mount point other than / (such as /usr), which gives
you a chicken-and-egg problem if mounting that mount point requires
lvm.
Uh... mounting filesystems is not the purview of {u,m}dev...
...yet ;)
That is, untill someone comes up with the clever idea of shoving an
automounter into udev. (Will it then also auto-unmount when I want my CD
back?)
--
Joost
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Fri, 16 Mar 2012 07:13:46 +0100, Joost Roeleveld wrote: Auto-starting programs when a device is added. Great, when are we getting autostart support for CDs and USB-keys and under which user-account will these be executed? This is for running programs from the computer against the device, not autorunning programs on the device - such as initialising USB modems. That is, untill someone comes up with the clever idea of shoving an automounter into udev. (Will it then also auto-unmount when I want my CD back?) That's already been done, * sys-apps/uam Available versions: 0.2.1 (~)0.3 Homepage:https://github.com/mgorny/uam/ Description: Simple udev-based automounter for removable USB media I also have a rule on a headless media server to run a script that mounts a USB stick, copies files to it, unmounts it and lets me know when it is done. I can mark files for copying at any time and my wife can just plug in a stick when she wants to copy them for viewing on a small, non-connected TV by her treadmill (her treadmill, I emphasise - I find a keyboard and trackball give me all the exercise I want). -- Neil Bothwick New Intel opcode #007 PUKE: Put unmeaningful keywords everywhere signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Friday, March 16, 2012 08:46:05 AM Neil Bothwick wrote: On Fri, 16 Mar 2012 07:13:46 +0100, Joost Roeleveld wrote: Auto-starting programs when a device is added. Great, when are we getting autostart support for CDs and USB-keys and under which user-account will these be executed? This is for running programs from the computer against the device, not autorunning programs on the device - such as initialising USB modems. How long till autorunning programs becomes the next great thing on the desktop for Linux? That is, untill someone comes up with the clever idea of shoving an automounter into udev. (Will it then also auto-unmount when I want my CD back?) That's already been done, * sys-apps/uam Available versions: 0.2.1 (~)0.3 Homepage:https://github.com/mgorny/uam/ Description: Simple udev-based automounter for removable USB media This is an automounter, not autounmounter... What I would like is one where a CDrom is automounted when inserted and when I press the eject-button, the cdrom is umounted and I get my cd back... The action that (used to) cause BSODs on MS Windows... I also have a rule on a headless media server to run a script that mounts a USB stick, copies files to it, unmounts it and lets me know when it is done. I can mark files for copying at any time and my wife can just plug in a stick when she wants to copy them for viewing on a small, non-connected TV by her treadmill (her treadmill, I emphasise - I find a keyboard and trackball give me all the exercise I want). Why not connect that TV? ;) -- Joost
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Fri, 16 Mar 2012 15:44:03 +0100, Joost Roeleveld wrote: This is for running programs from the computer against the device, not autorunning programs on the device - such as initialising USB modems. How long till autorunning programs becomes the next great thing on the desktop for Linux? When people want them... or when Canonical tell people they want them :( That is, untill someone comes up with the clever idea of shoving an automounter into udev. (Will it then also auto-unmount when I want my CD back?) That's already been done, * sys-apps/uam Available versions: 0.2.1 (~)0.3 Homepage:https://github.com/mgorny/uam/ Description: Simple udev-based automounter for removable USB media This is an automounter, not autounmounter... You said automounter. What I would like is one where a CDrom is automounted when inserted and when I press the eject-button, the cdrom is umounted and I get my cd back... That would require a more intelligent optical drive that sent a signal to the computer when the eject button was pressed. The computer could then run the eject command, which also unmounts the drive. Although that seem more the province of ACPI than udev. I also have a rule on a headless media server to run a script that mounts a USB stick, copies files to it, unmounts it and lets me know when it is done. I can mark files for copying at any time and my wife can just plug in a stick when she wants to copy them for viewing on a small, non-connected TV by her treadmill (her treadmill, I emphasise - I find a keyboard and trackball give me all the exercise I want). Why not connect that TV? ;) Because the hardware to do so would cost around £100, USB sticks cost rather less :P -- Neil Bothwick Puns are bad, but poetry is verse... signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On March 14, 2012 at 1:22 PM Canek Peláez Valdés can...@gmail.com wrote: Alan, the vast majority of Linux users right now are phone users. At least, that's how I see it. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. Right now Linux runs in my phone, my TV's, my routers and every computer I own. I have a couple of Windows installations, which I use once or twice every three months (I ported a PyGTK program to Windows last week, so I had to boot into Windows for the first time this year). I want Linux running on *everything*, and what is more: I don't want android in my handhelds, I want the full GNOME experience. Regards. -- What phone do you have running which Linux? I'm curious because a couple months ago we got new Samsung Galaxy S phones. I'd previously used an iPhone 3GS for a bit over a year. Since I can't stand Apple, as a company, it was with great joy that we could get 2 of these Galaxy S phones for free (with the 2-year contract, of course). -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Fri, Mar 16, 2012 at 10:20 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 14, 2012 at 1:22 PM Canek Peláez Valdés can...@gmail.com wrote: Alan, the vast majority of Linux users right now are phone users. At least, that's how I see it. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. Right now Linux runs in my phone, my TV's, my routers and every computer I own. I have a couple of Windows installations, which I use once or twice every three months (I ported a PyGTK program to Windows last week, so I had to boot into Windows for the first time this year). I want Linux running on *everything*, and what is more: I don't want android in my handhelds, I want the full GNOME experience. Regards. -- What phone do you have running which Linux? I'm curious because a couple months ago we got new Samsung Galaxy S phones. I'd previously used an iPhone 3GS for a bit over a year. Since I can't stand Apple, as a company, it was with great joy that we could get 2 of these Galaxy S phones for free (with the 2-year contract, of course). Sony XPeria Play, with Android 2.3.3, I believe. I'm a gamer. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Canek Peláez Valdés wrote: On Wed, Mar 14, 2012 at 1:41 PM, Michael Mol mike...@gmail.com wrote: [ huge snip ] Each time, you've acted as though the new stance is what you've been arguing from all along, but because you haven't communicated that, it's impossible to reasonably discuss specifics in practicality. I think I'm done with this particular discussion. I think I'm done too. I just stated my opinion; do whatever you want with it. Including ignoring it, of course. Regards. I already decided to do that. Someone makes a argument and you change the situation to fit your point then change again when someone points out that is not right either. This just continues on for infinity. I also don't folks like putting down the work Walt is doing. People are not liking where udev is going and are trying to do something different and all you do is belittle them for even trying. Back to my hole. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, 13 Mar 2012 23:43:54 +, Alan Mackenzie wrote: 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? Yes. They are simple rules under /etc/udev/rules.d that determine what to do when a device appears on the system, from giving it a specific name or setting permissions to running a program. It is the latter that causes problems when /usr is not mounted. 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. Yes we didi, but it's not going to go away any time soon :( 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. OK, here's another example. I have a box here with two USBRS232 adaptors, connected to completely different devices. The programs connecting to those devices need to be told which interface to communicate with, but you can't know in advance which will grab ttyUSB0 and which ttyUSB1. udev rules mean I can give them persistent names independent of the kernel assignments. One of the devices is a UPS, imagine the problems if both were UPSes and the software didn't know which was which - power fails to one and the software sends shutdown commands to the computers that still have power and let the others fail when the battery goes flat. 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. I wasn't suggesting you were being combative, hence the fair enough. You are seeing things from your perspective, as we all do (including the udev devs who made this decision) and it sounds like you have no need for any of this. Or maybe you do and don't know you are using it. Many programs install udev rulesets - for example sane-backends installs a 1500+ line (including comments) rule file, libgphoto's is not much smaller. all so you can connect a camera or scanner and not have to worry about how it is recognised or configured. 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. On the other hand, Gentoo's policy has been to follow upstream as closely as is practical, so if udev upstream wants /usr mounted early, that's what we do - or do without udev. Both are reasonable choices and Walt should be commended for his work on this, both on making it work and raising awareness of the alternative. I haven't yet decided which way I'll go, I'll probably give mdev a try on a non-desktop box, but it's good to have a choice and may the best option win. How do I set my laser printer to stun? How about a picture of Marilyn Monroe? ROFL. -- Neil Bothwick Will we ever get out of this airport? asked Tom interminably. signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
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 a...@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).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 2012-03-13 8:07 PM, Canek Peláez Valdés can...@gmail.com wrote: 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. 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. Very interesting thread guys, and thanks for keeping it relatively civil despite the passion behind the objections being raised... I just wanted to point out one thing (and ask a question about it) to anyone who argues that servers don't need this - if LVM2 really does eliminate the possibility of using mdev for fundamental reasons (as opposed to arbitrary decisions), that rules out a *lot* of server installations. So, that is my question... what is it about LVM2 that *requires* udev? Or asked another way - Why is LVM2 incapable od using mdev?
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2012-03-13 8:07 PM, Canek Peláez Valdés can...@gmail.com wrote: 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. 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. Very interesting thread guys, and thanks for keeping it relatively civil despite the passion behind the objections being raised... I just wanted to point out one thing (and ask a question about it) to anyone who argues that servers don't need this - if LVM2 really does eliminate the possibility of using mdev for fundamental reasons (as opposed to arbitrary decisions), that rules out a *lot* of server installations. So, that is my question... what is it about LVM2 that *requires* udev? Or asked another way - Why is LVM2 incapable od using mdev? The presumption is that lvm's dependent binaries would be found somewhere under a mount point other than / (such as /usr), which gives you a chicken-and-egg problem if mounting that mount point requires lvm. -- :wq
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 14, 2012 10:30 PM, Michael Mol mike...@gmail.com wrote:
On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl tansta...@libertytrek.org
wrote:
On 2012-03-13 8:07 PM, Canek Peláez Valdés can...@gmail.com wrote:
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.
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.
Very interesting thread guys, and thanks for keeping it relatively civil
despite the passion behind the objections being raised...
I just wanted to point out one thing (and ask a question about it) to
anyone
who argues that servers don't need this - if LVM2 really does eliminate
the
possibility of using mdev for fundamental reasons (as opposed to
arbitrary
decisions), that rules out a *lot* of server installations.
So, that is my question... what is it about LVM2 that *requires* udev?
Or asked another way -
Why is LVM2 incapable od using mdev?
Alan has explained that LVM2 actually is able to run under mdev, and he's
investigating if there's any LVM2 feature that is not available.
So far, there's none, and I'm strongly suspicious that it's a case of
missing dev symlinks that prevented LVM2 to work; something later on the
default runlevel then created the proper dev entries that allow LVM2 to
work.
If that is the case -- which I strongly suspect -- then one can use mdev's
built-in ability to rename/move a device + create a symlink [1]
[1]
https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/mdev.txt
The presumption is that lvm's dependent binaries would be found
somewhere under a mount point other than / (such as /usr), which gives
you a chicken-and-egg problem if mounting that mount point requires
lvm.
Uh... mounting filesystems is not the purview of {u,m}dev...
Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 14, 2012 10:20 PM, Alan Mackenzie a...@muc.de wrote: 8 snippage 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. This post here: http://lists.busybox.net/pipermail/busybox/2011-September/076662.html seems to indicate that Xorg communicates with udev (something mdev can't do, because that would increase the complexity of mdev by several orders of magnitude). BUT, in the same message, it is stated that Xorg *can* be compiled to *not* try to communicate with udev. I suspect a similar situation with Gnome. 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. Do packages *actually* need udev's (over)features (read: bloat), or is it just the maintainers depend-ing on sys-fs/udev instead of virtual/device-manager ? For lots of packages claiming they depend on udev, I suspect it's the latter situation. Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: 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 a...@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. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. 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. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. 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. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. 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. ^ That's your mistake! (IMHO). I explain below. I suspect the vast majority don't need it. Neither the typical desktop, the typical server, nor typical embedded devices like routers. Alan, the vast majority of Linux users right now are phone users. That was my initial point some mails ago. What *you* believe are regular users (people like you, or maybe even me), stopped being true a couple of years ago. The days of the Unix admin and workstation user are going the way of the dodo. At least, that's how I see it. 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. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. 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. No, it's not a matter of that's the way forward. It's a matter of trying to solve the general problem. And since the general solution also solves the simple cases, I don't see a reason to waste my time/resources in a
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
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? 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? 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? Stroller.
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com wrote: 8 snip That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. That could -- should -- be handled by a script or a program that looks up the database, do the checks, and rename the node accordingly. All the device manager got to do is to plug in into the hotplug kernel knob, whereby it will be invoked on every hotplug event, and depending on the nature if the device (which, in your example, fits the pattern wlan*) fires the script/program which performs the lookup+rename part. mdev can do that. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. Put it under /bin Done. Alan, the vast majority of Linux users right now are phone users. That was my initial point some mails ago. What *you* believe are regular users (people like you, or maybe even me), stopped being true a couple of years ago. The days of the Unix admin and workstation user are going the way of the dodo. At least, that's how I see it. The vast majority of Linux users, be they using PCs or smartphones, only need a mechanism to handle hotplugs. udev can do it, but so can mdev (with the help of helper scripts/programs). Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. See above. No, it's not a matter of that's the way forward. It's a matter of trying to solve the general problem. And since the general solution also solves the simple cases, I don't see a reason to waste my time/resources in a solution that in the end will not solve the general problem. It will always be simpler -- and easier to debug -- if we separate the hotplug handler (whose function is merely to create a dev node with the proper permissions and (optionally) fire up a 'configurator') from the configurator itself. udev is going the kitchen sink route. mdev stays the lego brick path. Of course, as I have been saying from the beginning, this is OpenSource. Want to pour some effort into solving the simple cases that will not help all the community, and that it will only help in fact a minority, that's your prerogative (and Walt's, and Vapier's, and everyone else that don't like the complex but complete solution). Go nuts with it if you want. The code is there; it's called mdev. But your emails are nothing short of denigrating the code. Talk about double standards :-) But please don't dismiss the general solution as unnecessary complex when it's not the case, and don't think that the simple setups (whatever that means) are the majority. Again, think phones and tablets: those *are* the majority. Again, see above. Oh, for sure you can modify LVM2 to work under mdev. Also GNOME/KDE/XFCE, and everything under the sun. You have the source; you can do *anything* you want with it. But the effort wasted^Hpoured in that excercise will only serve a handful of users, and it will be never accepted upstream, because upstream is (rightfully) concerned with the general problem. And as I have explained, based on what Alan had posted, LVM2 (for an example) probably only needs certain device nodes to exist, while mdev's default behavior is to not change anything unless explicitly told. Solvable easily, IMO. I'm more interested in the general solution that will work not only for my current machines, but also for the ones I'm planning to have in the future. I'm dying to get a tablet where I can put GNOME 3 on it; I can bet you another beer that mdev will be not enough to handle that. Unfortunately I don't have any Gentoo with GUI, so I can't take up on your offer :-( With all due respect, Alan (and this is completely sincere, in this list you are of the guys I respect the most), I believe you are thinking too small. With all due respect, I believe *you* are too defensive in regards to udev. Right now Linux runs in my phone, my TV's, my routers and every computer I own. I have a couple of Windows installations, which I use once or twice every three months (I ported a PyGTK program to Windows last week, so I had to boot into Windows for the first time this year). I want Linux running on *everything*, and what is more: I don't want android in my handhelds, I want the full GNOME experience. To accomplish that we need udev; mdev it's just not enough. Again, not necessarily. What exactly in Gnome requires udev? Is it merely expecting some device nodes to exist while mdev's default behavior doesn't do that? That would be simple to solve. A bit more difficult is if Gnome communicates with udev via libudev; but busybox devs have looked into the code of libudev, and found that the functions provided by that lib is can be emulated relatively quickly [1]. But he then added that he won't do that, because that would make
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: 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 a...@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. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. And I can always give an example where there can't be enough inodes (or perhaps even RAM) to contain enough device nodes. General Case is a beautiful thing for a theoretical system, but my computer is not a theoretical system. Neither is my phone, or my server. 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. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. udev does something nice here, and I believe mdev is capable of similar. sysfs exports device attributes such as model and serial number, and you could trivially derive the node name from that. 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. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. The userland bluetooth stack is an abomination. (Actually, the _whole_ bluetooth stack is an abomination. You don't want to know what embedded developers who build car stereos and the like have to go through to try to test things. Or what real packets fundamentally look like 'on the wire'.) It needs a real overhaul. I used to use a bluetooth keyboard, but I found it to be a real mess. I even joined the Linux Documentation Project with the intent of getting bluetooth profiles, apps and stacks indexed and cross-referenced, but there's just way too much going wrong with bluetooth. I eventually switched to using a propriety wireless keyboard, and relegated the bluetooth keyboard to secondary access and to controlling the PS3. Besides, your BIOS isn't going to support bluetooth, either; if you're concerned about failure-case recovery, and you don't have a keyboard you can navigate your BIOS with, you're very probably doing something wrong. 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. ^ That's your mistake! (IMHO). I explain below. I suspect the vast majority don't need it. Neither the typical desktop, the typical
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan pa...@poluan.info wrote: On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com wrote: 8 snip That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. That could -- should -- be handled by a script or a program that looks up the database, do the checks, and rename the node accordingly. All the device manager got to do is to plug in into the hotplug kernel knob, whereby it will be invoked on every hotplug event, and depending on the nature if the device (which, in your example, fits the pattern wlan*) fires the script/program which performs the lookup+rename part. mdev can do that. udev already does it. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. Put it under /bin Done. Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe I need a wireless connected NFS share). And... Not scalable. Doesn't solve the general case. You are seeing too small. Alan, the vast majority of Linux users right now are phone users. That was my initial point some mails ago. What *you* believe are regular users (people like you, or maybe even me), stopped being true a couple of years ago. The days of the Unix admin and workstation user are going the way of the dodo. At least, that's how I see it. The vast majority of Linux users, be they using PCs or smartphones, only need a mechanism to handle hotplugs. udev can do it, but so can mdev (with the help of helper scripts/programs). udev can do it *right now*, no hacks involved. Go and hack mdev until it handles *ALL* the cases udev handles, and see how complex it gets. Again, think about phones. And tablets. And TVs. And [insert-here-cool-gadgets-from-the-future]. See above. No, it's not a matter of that's the way forward. It's a matter of trying to solve the general problem. And since the general solution also solves the simple cases, I don't see a reason to waste my time/resources in a solution that in the end will not solve the general problem. It will always be simpler -- and easier to debug -- if we separate the hotplug handler (whose function is merely to create a dev node with the proper permissions and (optionally) fire up a 'configurator') from the configurator itself. Been there, tried that. What do you think devfs was? We tried this path already: it doesn't work, it doesn't scale. You couple together the device manager and the database handling and the firing of associated scripts because that's the technical correct solution. It *is* more complex, for sure, but so it's the general problem we are trying to solve. udev is going the kitchen sink route. mdev stays the lego brick path. And guess what? I don't want a toy solution built with lego blocks. I want a robust, general solution, that it is bound to work *now* and in the future. Of course, as I have been saying from the beginning, this is OpenSource. Want to pour some effort into solving the simple cases that will not help all the community, and that it will only help in fact a minority, that's your prerogative (and Walt's, and Vapier's, and everyone else that don't like the complex but complete solution). Go nuts with it if you want. The code is there; it's called mdev. But your emails are nothing short of denigrating the code. It's not my intention to denigrate anything. Just stating my opinion. Talk about double standards :-) When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may say that. Right *now*, Walt says mdev doesn't handle those cases. But please don't dismiss the general solution as unnecessary complex when it's not the case, and don't think that the simple setups (whatever that means) are the majority. Again, think phones and tablets: those *are* the majority. Again, see above. Oh, for sure you can modify LVM2 to work under mdev. Also GNOME/KDE/XFCE, and everything under the sun. You have the source; you can do *anything* you want with it. But the effort wasted^Hpoured in that excercise will only serve a handful of users, and it will be never accepted upstream, because upstream is (rightfully) concerned with the general problem. And as I have explained, based on what Alan had posted, LVM2 (for an example) probably only needs certain device nodes to exist, while mdev's default behavior is to not change anything unless explicitly told. Solvable easily, IMO. Go and solve it then. I will keep using udev, which works right now, thank you. I'm more interested in the general solution that will work not only for my current machines, but also for the ones I'm planning to have in the future. I'm dying to get a tablet where I can put GNOME 3 on it; I can bet you another beer that mdev will be not enough to handle that. Unfortunately
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 12:09 PM, Michael Mol mike...@gmail.com wrote: On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: 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 a...@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. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. And I can always give an example where there can't be enough inodes (or perhaps even RAM) to contain enough device nodes. General Case is a beautiful thing for a theoretical system, but my computer is not a theoretical system. Neither is my phone, or my server. You are arguing that the mknod method should be used? Because that dicussion happened ten years ago; that train is long gone. If you want to argue with someone about it, it would not be me. 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. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. udev does something nice here, and I believe mdev is capable of similar. sysfs exports device attributes such as model and serial number, and you could trivially derive the node name from that. I think (as does the udev maintainers) that there should be a strong coupling between the device manager, the database handling, and the firing of scripts. Otherwise. we get back to devfs, which again, that train is long gone. 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. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. The userland bluetooth stack is an abomination. (Actually, the _whole_ bluetooth stack is an abomination. You don't want to know what embedded developers who build car stereos and the like have to go through to try to test things. Or what real packets fundamentally look like 'on the wire'.) It needs a real overhaul. I used to use a bluetooth keyboard, but I found it to be a real mess. I even joined the Linux Documentation Project with the intent of getting bluetooth profiles, apps and stacks indexed and cross-referenced, but there's just way too much going wrong with bluetooth. I eventually switched to using a propriety wireless keyboard, and relegated the bluetooth keyboard to secondary access and to controlling the PS3. Besides, your BIOS isn't going to support bluetooth, either; if you're concerned about failure-case recovery, and you don't have a keyboard you can navigate your BIOS with, you're very probably doing something wrong. BIOS is going the way
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 15, 2012 1:22 AM, Canek Peláez Valdés can...@gmail.com wrote:
On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan pa...@poluan.info wrote:
On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com
wrote:
8 snip
That if I connect a USB wi-fi dongle, and it appears with the name
wlan23, I want *every* time that dongle to have the wlan23 name .Good
luck doing that without a database.
That could -- should -- be handled by a script or a program that looks
up
the database, do the checks, and rename the node accordingly.
All the device manager got to do is to plug in into the hotplug kernel
knob,
whereby it will be invoked on every hotplug event, and depending on the
nature if the device (which, in your example, fits the pattern wlan*)
fires the script/program which performs the lookup+rename part.
mdev can do that.
udev already does it.
So does mdev. If writing a simple script is so distressing for you, why in
the world are you using Gentoo, with all its manual labor?
Put it under /bin
Done.
Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe
I need a wireless connected NFS share). And...
Not scalable. Doesn't solve the general case. You are seeing too small.
*You* are not seeing _at all_. Witness how the Fedora devs want to merge
/bin and /sbin
It *is* scalable. Ever tried du /usr?
The problem was -- is -- that package maintainers blindly put binaries
required for booting into /usr
The vast majority of Linux users, be they using PCs or smartphones, only
need a mechanism to handle hotplugs.
udev can do it, but so can mdev (with the help of helper
scripts/programs).
udev can do it *right now*, no hacks involved. Go and hack mdev until
it handles *ALL* the cases udev handles, and see how complex it gets.
If you're so afraid of doing things manually, you have no business using
Gentoo in the first place.
Here's a prototype script to ensure that certain NICs will always end up
the way you want it named:
#!/bin/sh
mac=$( cat /proc/net/arp | awk -V dev=$MDEV 'NR==1{next} $6==dev {print
$4}')
name=$(awk -V mac=$mac '$1==mac {print $2}')
[ $name ] mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't test)
Been there, tried that. What do you think devfs was? We tried this
path already: it doesn't work, it doesn't scale. You couple together
the device manager and the database handling and the firing of
associated scripts because that's the technical correct solution. It
*is* more complex, for sure, but so it's the general problem we are
trying to solve.
If you step down from your high chair for awhile and read the busybox
thread I've been linking, you'll know the difference. One of the emails in
that thread explained it.
udev is going the kitchen sink route. mdev stays the lego brick path.
And guess what? I don't want a toy solution built with lego blocks.
Obviously idioms went way over your head.
If you're taking the Lego brick allegory as literal, then good luck with
your kitchen sink. At least I know that with Lego bricks, amazing works of
art have been created. :-P
I
want a robust, general solution, that it is bound to work *now* and in
the future.
So? What makes you think that in the future suddenly mdev stops working?
The flip side: as udev gets more and more complex, how could you be sure it
won't catastrophically fail one day, just like HAL?
Talk about double standards :-)
When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may
say that. Right *now*, Walt says mdev doesn't handle those cases.
Walt said that mdev doesn't work with LVM2, but then Alan said that
actually LVM2 works after booting. It just didn't work during booting.
Suspiciously a case of missing/misnamed dev nodes to me, easily fixable by
adding some mdev.conf rules.
Go and solve it then. I will keep using udev, which works right now,
thank you.
I am not using LVM, so I have no test case. But I certainly will pursue
this issue -- had you not derail the thread by slandering mdev with all
your might.
With all due respect, Alan (and this is completely sincere, in this
list you are of the guys I respect the most), I believe you are
thinking too small.
With all due respect, I believe *you* are too defensive in regards to
udev.
I'm not defending anything; just stating my opinion. You are free to
disagree, of course.
The way you write it, as if udev is the greatest thing since slice bread
while mdev is 'useless and destined to fail'?
Sounds like a fanboy rant to me :-)
Go and code if it's really easy and simple and doable. Me? I will
stick with udev, 'cause it works. And it works *right now*, in all my
use cases and even some I don't plan to have in the near future.
If it's a case of missing node, it's *very* easy: Identify what node it's
being expected, identify what node was created by mdev, edit mdev.conf to
perform a
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 15, 2012 2:24 AM, Pandu Poluan pa...@poluan.info wrote:
Here's a prototype script to ensure that certain NICs will always end up
the way you want it named:
#!/bin/sh
mac=$( cat /proc/net/arp | awk -V dev=$MDEV 'NR==1{next} $6==dev {print
$4}')
name=$(cat /etc/nic.conf | awk -V mac=$mac '$1==mac {print $2}')
[ $name ] mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't
test)
Eh, forgot the input file for the second awk :-P
Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 2:45 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 12:09 PM, Michael Mol mike...@gmail.com wrote: On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie a...@muc.de wrote: 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 a...@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. Again, I believe you are not following me. In *general* the number of potential device files under /dev is not bounded. Given N device filess, I can give you an example where you would need N+1 device files. With your experience, I assume you know about huge arrays of SCSI disks, for example; add to that whatever number of USB devices (and the hubs necessary to connect them), whatever number of Bluetooth thingies, etc., etc. Therefore, mknod doesn't solve the problem in general, because I can always give an example where the preset device files on /dev are not enough. And I can always give an example where there can't be enough inodes (or perhaps even RAM) to contain enough device nodes. General Case is a beautiful thing for a theoretical system, but my computer is not a theoretical system. Neither is my phone, or my server. You are arguing that the mknod method should be used? Because that dicussion happened ten years ago; that train is long gone. If you want to argue with someone about it, it would not be me. No, I was taking your argument to its perceived end result. You want the universal solution, but that requires limitless resources in things like memory and integer sizes. The software doesn't exist within such an environment. The assumptions which it's already depending on limit its utility in lower-end hardware. 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. That if I connect a USB wi-fi dongle, and it appears with the name wlan23, I want *every* time that dongle to have the wlan23 name .Good luck doing that without a database. udev does something nice here, and I believe mdev is capable of similar. sysfs exports device attributes such as model and serial number, and you could trivially derive the node name from that. I think (as does the udev maintainers) that there should be a strong coupling between the device manager, the database handling, and the firing of scripts. Otherwise. we get back to devfs, which again, that train is long gone. From the sound of it, it sounds like mdev matches that description. mdev supports the renaming of devices, so there's your database. It supports firing scripts. 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. Bluetooth keyboards. Done, you made my system unbootable when I need to run fsck by hand after a power failure. The userland bluetooth stack is an abomination. (Actually, the _whole_ bluetooth stack is an abomination. You don't want to know what embedded developers who build car stereos and the like have to go through to try to test things. Or what real packets fundamentally look like 'on the wire'.) It needs a real overhaul. I used to use a bluetooth keyboard, but I found it to be a real mess. I even joined the Linux
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 1:24 PM, Pandu Poluan pa...@poluan.info wrote:
On Mar 15, 2012 1:22 AM, Canek Peláez Valdés can...@gmail.com wrote:
On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan pa...@poluan.info wrote:
On Mar 15, 2012 12:25 AM, Canek Peláez Valdés can...@gmail.com
wrote:
8 snip
That if I connect a USB wi-fi dongle, and it appears with the name
wlan23, I want *every* time that dongle to have the wlan23 name .Good
luck doing that without a database.
That could -- should -- be handled by a script or a program that looks
up
the database, do the checks, and rename the node accordingly.
All the device manager got to do is to plug in into the hotplug kernel
knob,
whereby it will be invoked on every hotplug event, and depending on the
nature if the device (which, in your example, fits the pattern wlan*)
fires the script/program which performs the lookup+rename part.
mdev can do that.
udev already does it.
So does mdev. If writing a simple script is so distressing for you, why in
the world are you using Gentoo, with all its manual labor?
Whoa, relax man. We are discussing (or at least I'm trying) in a civil
manner the technical merits of two proposed solutions for a problem.
No need to get personal.
(And BTW, I've been using Gentoo since 2003, and I maintain an overlay
to use systemd without the need of having openrc/baselayout
installed).
Put it under /bin
Done.
Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe
I need a wireless connected NFS share). And...
Not scalable. Doesn't solve the general case. You are seeing too small.
*You* are not seeing _at all_. Witness how the Fedora devs want to merge
/bin and /sbin
Yeah. I agree with their decision. Read:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
It *is* scalable. Ever tried du /usr?
Yeah, from time to time. Fail to see your point.
The problem was -- is -- that package maintainers blindly put binaries
required for booting into /usr
No problem with an intiramfs :D
The vast majority of Linux users, be they using PCs or smartphones, only
need a mechanism to handle hotplugs.
udev can do it, but so can mdev (with the help of helper
scripts/programs).
udev can do it *right now*, no hacks involved. Go and hack mdev until
it handles *ALL* the cases udev handles, and see how complex it gets.
If you're so afraid of doing things manually, you have no business using
Gentoo in the first place.
Again with the personal attacks; relax man. No need to get all worked out.
Here's a prototype script to ensure that certain NICs will always end up the
way you want it named:
#!/bin/sh
mac=$( cat /proc/net/arp | awk -V dev=$MDEV 'NR==1{next} $6==dev {print
$4}')
name=$(awk -V mac=$mac '$1==mac {print $2}')
[ $name ] mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't test)
Yeah, I'm gonna try that instead of udev, which works out of the box.
I'm gonna pass, thank you.
Been there, tried that. What do you think devfs was? We tried this
path already: it doesn't work, it doesn't scale. You couple together
the device manager and the database handling and the firing of
associated scripts because that's the technical correct solution. It
*is* more complex, for sure, but so it's the general problem we are
trying to solve.
If you step down from your high chair for awhile and read the busybox thread
I've been linking, you'll know the difference. One of the emails in that
thread explained it.
Relax, I'm not on a high chair; again, I'm just stating my opinion. I
have read the mail, I think the day it was posted. I don't buy it, for
all the reasons I have been saying.
udev is going the kitchen sink route. mdev stays the lego brick path.
And guess what? I don't want a toy solution built with lego blocks.
Obviously idioms went way over your head.
If you're taking the Lego brick allegory as literal, then good luck with
your kitchen sink. At least I know that with Lego bricks, amazing works of
art have been created. :-P
:D
Actually, a Lego brick is a good analogy for mdev (in its current
state). It's a beautiful toy; but again, nobody has pointed out how to
make it work with bluetooth devices, for example. From Walt's mail
(his words, not mine):
This revision includes some checking to see if your system can run
without udev. In general, if you use any of...
* GNOME
* KDE
* XFCE
* lvm2
... you probably need udev, so mdev is not for you.
I
want a robust, general solution, that it is bound to work *now* and in
the future.
So? What makes you think that in the future suddenly mdev stops working?
I doesn't work, out of the box, right now. Again, see Walt's mail.
The flip side: as udev gets more and more complex, how could you be sure it
won't catastrophically fail one day, just like HAL?
Educated guess ;)
I have been using Linux since 1997. I
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 1:41 PM, Michael Mol mike...@gmail.com wrote: [ huge snip ] Each time, you've acted as though the new stance is what you've been arguing from all along, but because you haven't communicated that, it's impossible to reasonably discuss specifics in practicality. I think I'm done with this particular discussion. I think I'm done too. I just stated my opinion; do whatever you want with it. Including ignoring it, of course. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Good evening, Stroller. On Wed, Mar 14, 2012 at 05:56:34PM +, 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).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 2012-03-14 19:45, Canek Peláez Valdés wrote: BIOS is going the way of the dodo too, but that's besides the point. I'm actually quite happy with the Linux bluetooth stack (which, if I'm not mistaken, is used by Android). I have several bluetooth thingies, they all work great. Sorry, but you're gravely mistaken if you think firmware[1] is going anywhere. You can have all the bluetooth thingies you want but why should they be available at boot time, before you can use them? Excepting a bluetooth keyboard, which to me seems broken by design; you're replacing a keyboard with a cable that just works with something that needs a system up and running to function... [1] (U)EFI is only replacing the runtime interface of BIOS (BIOS will remain). https://en.wikipedia.org/wiki/BIOS#Changing_role_of_the_BIOS And if you want to ditch BIOS altogheter you need to replace it with something like coreboot or Open Firmware. Best regards Peter K
RE: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
From: Alan Mackenzie [mailto:a...@muc.de] Sent: Tuesday, March 13, 2012 7:04 PM 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. This idea works fine when your drivers are simple enough to go into a kernel, and can actually perform all of the functions your device needs. Many modern devices require complex things to happen before or after they appear in your /dev tree before they can *really* be useful. (Complex relative to the operations a kernel module is expected to perform). When I plug in my HP USB printer, the hplip system checks a locally installed database file to make sure I have support for that model before making it available as a device. When udev finds my Bluetooth keyboard or mouse, it launches bluetoothd so it will work. udev manages drives, sound cards and network cards that may appear and disappear in such a way that they are always given consistent names. I have custom rules that run when I plug an Android phone into my machine that preps it for being debugged via Eclipse, despite the kernel seeing it as just a generic USB device. The point is, udev suppors /arbitrary/ behaviors, defined by device vendors or even end users, which can be controlled and configured at runtime. Some of these operations would be hard to do safely from the kernel. Some of them may even trigger events to happen in userspace in the context of the logged-on user (such as automounting from GNOME.) Note that none of this is necessarily unique to udev; mdev could (and probably does, I don't know) provide userspace events for new devices just as easily as udev does. But in order for udev to maintain the broad level of complex hardware support that it has, it must make certain assumptions that may not hold true for /all/ cases, but are true in the /broadest general/ case: that it may be required to launch software or read data found in /usr or /home or wherever else a udev rule might point, and it may be required to do so before it has even seen the device nodes needed to mount non-root partitions. mdev's appeal here in this case is simply that it makes different, simpler assumptions: that it will /never/ need to access software or data that is not part of the root partition at boot time. If that assumption holds true for a given system, then mdev can behave as an effective drop-in replacement for udev. The choice is then to give up support for the broader case in exchange for a simpler system that supports enough to make all of your specific hardware function. --Mike
RE: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
From: Pandu Poluan [mailto:pa...@poluan.info] Sent: Wednesday, March 14, 2012 12:13 PM BUT, in the same message, it is stated that Xorg *can* be compiled to *not* try to communicate with udev. I suspect a similar situation with Gnome. IIRC, GNOME only needs udev for auto-mount support. gvfs has a udev flag, disabling that might eliminate the need there. KDE has similar udev flags for things like pulseaudio. For GNOME, I suspect swapping udev for mdev may be tricky, since GNOME uses a custom-build library (libudev) for all of its communications. If libudev can be tricked into listening to mdev instead, and isn't communicating in a way that mdev doesn't support, then GNOME should just work. --Mike
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 03:16:20PM +, Alan Mackenzie wrote 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. I don't have x11-drivers/xf86-input-evdev installed and my desktops work fine. Of course, I'm running ICEWM, not GNOME or KDE. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 2012-03-14 20:45, Canek Peláez Valdés wrote: Actually, a Lego brick is a good analogy for mdev (in its current state). It's a beautiful toy; but again, nobody has pointed out how to make it work with bluetooth devices, for example. From Walt's mail (his words, not mine): You're completely missing the point about lego. Lego in this context means small, well defined, interoperable parts with well defined interfaces (i.e. unix); small means easy to maintain (less complex). And if you wish to play it like that: Your system (systemd, pulseaudio, bluetooth, diverse gadgetry...) seems much more of a toy system to me... * XFCE Not sure why it would be a problem running Xfce without udev support: http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors ... maybe things will change though... Gnome and KDE *I* couldn't care less about; they're focused more on singing and dancing than productivity... * lvm2 Alan Mackenzie seems to be able to run it with mdev... I'm willing to bet yet another beer that udev will not have the fate HAL had. As complexity grows, bugs will too... which is why the unix concept have worked for so long (KISS = lego). Best regards Peter K
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Wed, Mar 14, 2012 at 05:56:34PM +, Stroller wrote 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? 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? ...and auto-execute an INI file that loads a virus, or Sony rootkit? No thanks. BTW, even with mdev, a bunch of stuff gets spit out to /var/log/messages. The last line was... Mar 14 20:17:42 localhost kernel: [512417.398747] sd 7:0:0:0: [sdb] Attached SCSI removable disk This is probably what userspace automounters work with (directly or indirectly). -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Tue, 13 Mar 2012 02:41:15 + Peter Humphrey pe...@humphrey.ukfsn.org wrote: On Monday 12 March 2012 12:21:17 Neil Bothwick wrote: On Sun, 11 Mar 2012 22:34:27 +0200, Alan McKinnon wrote: My mother swears blind I watched England win the World Cup but I don't remember (being only 1 year old at the time). I fell asleep during it. To be fair I was nine and had just had an overnight car journey returning from holiday. I can't remember it at all, even though I was 23 or so. (Aside: my father used to say that football is a game, and games are what children play.) Football is not a game. Football is a religion. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mon, Mar 12, 2012 at 09:24:32AM +, Alan Mackenzie wrote Help would be appreciated. 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-::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. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mon, Mar 12, 2012 at 09:24:32AM +, 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. 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. 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. Again, sorry about putting you through this trouble. You did what a beta tester is supposed to do, i.e. find problems/bugs. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Tue, 13 Mar 2012 02:41:15 +, Peter Humphrey wrote: I can't remember it at all, even though I was 23 or so. (Aside: my father used to say that football is a game, and games are what children play.) Yes, but that doesn't mean no one else plays them. That's the sort of argument that could only be used by a parent on a child :-O -- Neil Bothwick We can sympathize with a child who is afraid of the dark, but the tragedy of life is that most people are afraid of the light. signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Hello, Walter. On Tue, Mar 13, 2012 at 03:14:55AM -0400, Walter Dnes wrote: On Mon, Mar 12, 2012 at 09:24:32AM +, 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-::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 waltd...@waltdnes.org -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Hi, Walter.
On Tue, Mar 13, 2012 at 03:33:06AM -0400, Walter Dnes wrote:
On Mon, Mar 12, 2012 at 09:24:32AM +, 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 waltd...@waltdnes.org
--
Alan Mackenzie (Nuremberg, Germany).
mdev.tar.gz
Description: Binary data
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Tuesday 13 March 2012 11:01:29 Neil Bothwick wrote: On Tue, 13 Mar 2012 02:41:15 +, Peter Humphrey wrote: I can't remember it at all, even though I was 23 or so. (Aside: my father used to say that football is a game, and games are what children play.) Yes, but that doesn't mean no one else plays them. That's the sort of argument that could only be used by a parent on a child :-O It is indeed true that, on the rare occasion I've used it myself, it hasn't done me any good. :-) -- Rgds Peter
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 01:05:34PM +, 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.
--
Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Hello, Walter,
On Tue, Mar 13, 2012 at 03:00:52PM -0400, Walter Dnes wrote:
On Tue, Mar 13, 2012 at 01:05:34PM +, 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 waltd...@waltdnes.org
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 1:47 PM, Alan Mackenzie a...@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 +, 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).
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.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On March 13, 2012 at 4:27 PM Canek Peláez Valdés can...@gmail.com wrote: snip 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. Regards. -- Canek Peláez Valdés It _sounds_ like your definition of a fringe program is one that does not need udev; but when it becomes mainstream it will need udev. If not, you write us the definition of a fringe program and a mainstream program. Excuse me, but that's just incredibly _arrogant_! I wasn't getting into this ridiculous discussion, but your irresponsible ranting... Yes, I dedicate my Linux life to killing FUD, and that post of yours is FUD! I'm from the South, where FUD is colloquially called bullmanure. :-)} Below are some mainstream programs that my every computer on the LAN in my computer business uses _every_ day which don't require udev: x11-terms/rxvt-unicode app-editors/vim net-misc/dhcpcd ... The more I think about your arrogance, the more ticked off I get! Here's the very few packages on my workstation that _do_ require udev: mingdao@workstation ~ $ equery depends udev * These packages depend on udev: media-libs/libcanberra-0.28-r5 (udev ? =sys-fs/udev-160) media-libs/mesa-7.11.2 (gbm ? sys-fs/udev) media-video/vlc-1.1.13 (udev ? =sys-fs/udev-142) net-print/hplip-3.11.10 (acl ? =sys-fs/udev-171[acl]) (acl ? =sys-fs/udev-145[extras]) (kernel_linux ? =sys-fs/udev-114) sys-fs/lvm2-2.02.88 (=sys-fs/udev-151-r4) 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-libs/libva-1.0.15 (video_cards_dummy ? sys-fs/udev) Perhaps it would be ridiculously easy to get rid of udev on this box. But, that's not the point I'm making here. It's not so much that udev is evil, to me; but that requiring an initrd is stupid. And, it's not so much udev vs. mdev or whatever, but that your attitude _STINKS_! Geez... -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
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 a...@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 +, 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).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 13, 2012 at 4:27 PM Canek Peláez Valdés can...@gmail.com wrote: snip 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. Regards. -- Canek Peláez Valdés It _sounds_ like your definition of a fringe program is one that does not need udev; but when it becomes mainstream it will need udev. If not, you write us the definition of a fringe program and a mainstream program. Excuse me, but that's just incredibly _arrogant_! Relax man. That's why fringe is written QUOTE fringe UNQUOTE, and mainstream is written QUOTE mainstream UNQUOTE. If it makes you happy, replace fringe with GNOME/KDE/XFCE/lvm2-not-related and mainstream with GNOME/KDE/XFCE/lvm2-related. That's using the very same definition that Walter (the guy behind the mdev-instead-of-udev effort) used just three mails below (or above, depending on your email client). Please chill, no need to get all worked out. And I maintain my prediction. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, 13 Mar 2012 21:07:37 +, 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. 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. 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. 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. -- Neil Bothwick ... I dropped my toothpaste, Tom said, Crestfallen. signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On March 13, 2012 at 5:22 PM Canek Peláez Valdés can...@gmail.com wrote: On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 13, 2012 at 4:27 PM Canek Peláez Valdés can...@gmail.com wrote: snip 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. Regards. -- Canek Peláez Valdés It _sounds_ like your definition of a fringe program is one that does not need udev; but when it becomes mainstream it will need udev. If not, you write us the definition of a fringe program and a mainstream program. Excuse me, but that's just incredibly _arrogant_! Relax man. That's why fringe is written QUOTE fringe UNQUOTE, and mainstream is written QUOTE mainstream UNQUOTE. If it makes you happy, replace fringe with GNOME/KDE/XFCE/lvm2-not-related and mainstream with GNOME/KDE/XFCE/lvm2-related. That's using the very same definition that Walter (the guy behind the mdev-instead-of-udev effort) used just three mails below (or above, depending on your email client). Please chill, no need to get all worked out. And I maintain my prediction. Regards. -- Canek Peláez Valdés So, what qualifies for the moment a fringe program reaches critical mass to become maistream, the probability of it needing udev (directly or indirectly) will increase. Again, quoting _your_ definition. I gave you examples of programs which have reached critical mass, which don't require udev. And, I'm not attaching your character, for I know you not ... just attacking your FUD! -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 3:35 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 13, 2012 at 5:22 PM Canek Peláez Valdés can...@gmail.com wrote: On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 13, 2012 at 4:27 PM Canek Peláez Valdés can...@gmail.com wrote: snip 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. Regards. -- Canek Peláez Valdés It _sounds_ like your definition of a fringe program is one that does not need udev; but when it becomes mainstream it will need udev. If not, you write us the definition of a fringe program and a mainstream program. Excuse me, but that's just incredibly _arrogant_! Relax man. That's why fringe is written QUOTE fringe UNQUOTE, and mainstream is written QUOTE mainstream UNQUOTE. If it makes you happy, replace fringe with GNOME/KDE/XFCE/lvm2-not-related and mainstream with GNOME/KDE/XFCE/lvm2-related. That's using the very same definition that Walter (the guy behind the mdev-instead-of-udev effort) used just three mails below (or above, depending on your email client). Please chill, no need to get all worked out. And I maintain my prediction. Regards. -- Canek Peláez Valdés So, what qualifies for the moment a fringe program reaches critical mass to become maistream, the probability of it needing udev (directly or indirectly) will increase. Just what I was saying: I said (right there) the probability of it needing udev (directly or indirectly) will increase. I did not say it would *need* udev for sure; just that the probability of it needing udev would increase. I'm not spreading FUD; I'm just stating my opinion. And I stick to it; wanna bet that beer? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, 13 Mar 2012 17:35:05 -0400 (EDT) Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 13, 2012 at 5:22 PM Canek Peláez Valdés can...@gmail.com wrote: On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 13, 2012 at 4:27 PM Canek Peláez Valdés can...@gmail.com wrote: snip 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. Regards. -- Canek Peláez Valdés It _sounds_ like your definition of a fringe program is one that does not need udev; but when it becomes mainstream it will need udev. If not, you write us the definition of a fringe program and a mainstream program. Excuse me, but that's just incredibly _arrogant_! Relax man. That's why fringe is written QUOTE fringe UNQUOTE, and mainstream is written QUOTE mainstream UNQUOTE. If it makes you happy, replace fringe with GNOME/KDE/XFCE/lvm2-not-related and mainstream with GNOME/KDE/XFCE/lvm2-related. That's using the very same definition that Walter (the guy behind the mdev-instead-of-udev effort) used just three mails below (or above, depending on your email client). Please chill, no need to get all worked out. And I maintain my prediction. Regards. -- Canek Peláez Valdés So, what qualifies for the moment a fringe program reaches critical mass to become maistream, the probability of it needing udev (directly or indirectly) will increase. I'll start the reply with a joke. I read a tongue-in-cheek post somewhere recently (maybe even here) that for a program to be considered successful at MIT it always gets to a point where it can send and receive mail. Any program that can't send and receive mail is obviously not yet good enough for real-world use. Very tongue-in-cheek. But it's true enough. Hell, the monitoring guys at work use SMTP as transport for several time-critical monitor probes (a delay of 5 minutes causes all hell to break loose...) Why SMTP you ask? Well, because it's there. Because it's ubiquitous. Because you can panelbeat it to make it work even when you shouldn't. Because corporate coders are lazy. Because corporate coders don't know any better. Because all of the above. I really doubt the majority of apps requiring udev actually require udev itself. Maybe they just need nodes, or only need a node manager. Most likely, the dev looked at the scene, listed his possibilities and saw... udev, and nothing else. Therefore it requires udev. Which is about as logical as requiring /usr/ if you think about it. Changing this will take a huge mindshift on the part of large developer communities (outside of udev) to consider other possibilities. This will take a while, much like wrestling market share away from Apache. Again, quoting _your_ definition. I gave you examples of programs which have reached critical mass, which don't require udev. And, I'm not attaching your character, for I know you not ... just attacking your FUD! I'm in the let's not emulate Microsoft with udev camp myself, but I also see the bigger picture. It's not only that udev is pushing it's agenda on the rest of the stack, one must also consider that the rest of the stack is doing things that require udev to react, and one of the fallout cases is separate /usr needing initramfs. I personally don't like it but I think I understand the ecosystem that produced it. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Hello, Neil. On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote: On Tue, 13 Mar 2012 21:07:37 +, 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).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On March 13, 2012 at 5:49 PM Canek Peláez Valdés can...@gmail.com wrote: Just what I was saying: I said (right there) the probability of it needing udev (directly or indirectly) will increase. I did not say it would *need* udev for sure; just that the probability of it needing udev would increase. And I call FUD! I'm not spreading FUD; I'm just stating my opinion. And I stick to it; wanna bet that beer? I don't bet or drink, but will say you're right if you produce verifiable facts. Regards. -- Canek Peláez Valdés -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie a...@muc.de wrote: Hello, Neil. On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote: On Tue, 13 Mar 2012 21:07:37 +, 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. 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. They need to handle lots of different hardware comming and going, via USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future. 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. This is overkill for our old and beloved beige boxen? In some cases; not in mine, where I have bluetooth headphones, cell phones, and gamepads, and USB speakers, or where I connect different LCD/LED TVs to my machines. But for some very specific cases it is overkill, in the sense that fuel injection is overkill to get a car moving. And the guys pushing this changes believe that we don't need to cater to the simple beige box (usually servers) crowd anymore: we already got them. We need to cater to everybody else: in particular, at this moment (if the analysts numbers are right) the users of Linux in cellphones surpases the users of Linux in beige boxen... and by a lot it seems. We need to focus in them, and hope they will ask for Linux in their beige boxen if they like their other gadgets. We can discuss the merits of their plan, but I for one I'm with them. I've been using Linux more than 15 years, and with my GNOME 3 system today (yes, with udev, and systemd, and PulseAudio) I'm much more productive than with the command line 10 years ago. My servers run systemd; they not need it, in the sense that they could work without it (and my car run without fuel injection). But I'm very happy with the features running systemd in a server gives me (and the fuel efficiency the fuel injection gives my car). So, yeah, it's more complicated. The world got complicate; better get used to it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 4:36 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 13, 2012 at 5:49 PM Canek Peláez Valdés can...@gmail.com wrote: Just what I was saying: I said (right there) the probability of it needing udev (directly or indirectly) will increase. I did not say it would *need* udev for sure; just that the probability of it needing udev would increase. And I call FUD! Call all you want mate, doesn't make it true ;) I'm not spreading FUD; I'm just stating my opinion. And I stick to it; wanna bet that beer? I don't bet or drink, but will say you're right if you produce verifiable facts. I'm making a prediction, man. The only verifiable fact is in the future, and my crystall ball is in the shop. And I don't care if you (or anybody for that matter) says that I'm right or wrong. I'm just stating my opinion. And I will keep stating it. And really, relax. We are all on gentoo-user trying to learn a little and get (or give) help from time to time. That's all. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, 13 Mar 2012 22:20:19 +, 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. 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. 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. 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. 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. -- Neil Bothwick How do I set my laser printer to stun? signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
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 a...@muc.de wrote: Hello, Neil. On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote: On Tue, 13 Mar 2012 21:07:37 +, 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).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 11:03:50PM +, Neil Bothwick wrote: On Tue, 13 Mar 2012 22:20:19 +, 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).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie a...@muc.de wrote: 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 a...@muc.de wrote: Hello, Neil. On Tue, Mar 13, 2012 at 09:33:30PM +, Neil Bothwick wrote: On Tue, 13 Mar 2012 21:07:37 +, 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. 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*. 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. 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. 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. [ ] So, yeah, it's more complicated. The world got complicate;
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On Mar 14, 2012 7:10 AM, Canek Peláez Valdés can...@gmail.com wrote: 8 snippage 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. 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. 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. FWIW, mdev is perfectly capable of handling device events, and (optionally) firing an arbitrary script. The way I see it, udev is trying to be everything regarding devices, while mdev is purposefully limiting itself to creating proper nodes under /dev. That (udev's wanting to do *everything*) to me seems counter against the philosophy of Unix-y apps: do one thing, and do it well. And that's why I don't like udev; for it to be able to do everything under the sun, it needs stuffs. Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
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 waltd...@waltdnes.org -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, 11 Mar 2012 22:34:27 +0200, Alan McKinnon wrote: My mother swears blind I watched England win the World Cup but I don't remember (being only 1 year old at the time). I fell asleep during it. To be fair I was nine and had just had an overnight car journey returning from holiday. -- Neil Bothwick PC DOS Error #01: Windows loading, come back tomorrow signature.asc Description: PGP signature
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On 2012-03-11 20:28, Walter Dnes wrote: which blob to load. But, if I leave only the correct blob for my GPU in the library folder (move/delete all the others), it loads properly without any help from udev. Why not compile the firmware into the kernel? http://en.gentoo-wiki.com/wiki/Radeon#With_a_built-in_driver PS. Thanks for what you are doing! I'll try to find some time in the near future to try mdev out! Best regards Peter K
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On 2012-03-11 15:17, Alan McKinnon wrote: As such, mdev is a good fit and we can add Walter to the long list of people before him who selflessly worked to make our software work better. Very well put, Alan! +1 Thanks Walter! Best regards Peter K
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
On 2012-03-12 10:24, Alan Mackenzie wrote: #!/bin/busybox ash mount -t proc proc /proc mount -t sysfs sysfs /sys exec /sbin/init 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? Well, you can always put in: echo linuxrc executing! sleep 5s #I put this here since I suspect it will flash by... before the 'exec /sbin/init' line (or the mount lines) in the linuxrc script above... HTH Best regards Peter K
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Monday 12 March 2012 12:21:17 Neil Bothwick wrote: On Sun, 11 Mar 2012 22:34:27 +0200, Alan McKinnon wrote: My mother swears blind I watched England win the World Cup but I don't remember (being only 1 year old at the time). I fell asleep during it. To be fair I was nine and had just had an overnight car journey returning from holiday. I can't remember it at all, even though I was 23 or so. (Aside: my father used to say that football is a game, and games are what children play.) -- Rgds Peter
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On March 11, 2012 at 5:09 AM Walter Dnes waltd...@waltdnes.org 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 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 -- Walter Dnes waltd...@waltdnes.org Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. Kindest regards, Bruce
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Mar 11, 2012 6:30 PM, Daddy da...@happypenguincomputers.com wrote: On March 11, 2012 at 5:09 AM Walter Dnes waltd...@waltdnes.org 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 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 -- Walter Dnes waltd...@waltdnes.org Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. I'm one of the long-suffering beta-tester for Walt ;-) I've tested all his procedures (except this one), and up to now found no problems. One caveat: my tests are all on servers (test-dev-staging-production). We -- that is, Gentoo users who want to go udev-less -- will certainly appreciate feedback from desktop users. Rgds,
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, 11 Mar 2012 07:27:05 -0400 (EDT) Daddy da...@happypenguincomputers.com wrote: On March 11, 2012 at 5:09 AM Walter Dnes waltd...@waltdnes.org 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 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 -- Walter Dnes waltd...@waltdnes.org Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? No, it's his reaction to the fantastical amount of kitchen-sinking going on surrounding udev. Most specifically, it's the recent requirement foisted on the udev-using community to require either /usr to be part of / or to use an initramfs. Walter simply wants to show that mdev is a suitable replacement for udev in simple environments eg embedded, simple desktops without complex hotplug requirements, and servers. Canek will no doubt chip in about how this is the way things are going, it is inevitable, the boot sequence is becoming complex and various other rehashings of what's coming out of udev upstream. However, something needs to be pointed out in that regard. What udev upstream is saying is probably quite true, but only within the limits of the environment in which they work and udev is designed to handle - sophisticated desktops. The three cases I mentioned are perfectly valid use-cases, comprise a large percentage of the Linux installed base, should be catered to and have no need of the sophistication current udev aims to provide. As such, mdev is a good fit and we can add Walter to the long list of people before him who selflessly worked to make our software work better. One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. Welcome to the list, you'll soon get to know all the personalities here. We have at least one of everything - class clowns, old farts, newbies, voices of reason, influential devs and even the occasional fellow who knows what he's talking about. :-) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, Mar 11, 2012 at 8:17 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Sun, 11 Mar 2012 07:27:05 -0400 (EDT) Daddy da...@happypenguincomputers.com wrote: On March 11, 2012 at 5:09 AM Walter Dnes waltd...@waltdnes.org 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 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 -- Walter Dnes waltd...@waltdnes.org Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? No, it's his reaction to the fantastical amount of kitchen-sinking going on surrounding udev. Most specifically, it's the recent requirement foisted on the udev-using community to require either /usr to be part of / or to use an initramfs. Walter simply wants to show that mdev is a suitable replacement for udev in simple environments eg embedded, simple desktops without complex hotplug requirements, and servers. Canek will no doubt chip in about how this is the way things are going, it is inevitable, the boot sequence is becoming complex and various other rehashings of what's coming out of udev upstream. No, I will not ;) As I have said before, I admire a lot what Walter et al. are doing, and as I always will say, this is how our community works: people writing the code (as Walter is doing) are the ones that get things done. This is the correct (and only) way to address a problem (perceived or real) with the current status: write the code that does the thing the way you want it. Complaining and crying that you don't like the direction some part of the stack is taking is at best a waste of time, and at worst idiotic. Actually doing something about it (as Walter is doing) is the smart thing to do. I personally will not use Walt's work. Not in my desktop, laptop, nor in my servers or embedded systems (I don't know if my Media Center qualifies as embedded, if I'm truthful); they all run amazingly well with systemd. But that's my decision: if anybody else wants to go the mdev route, that's their absolute right. This is open source: code talks. If anyone with enough interest and capabilities wants to implement any feature (or anti feature) they want, they will. That's what Walter is doing, and I sincerely salute that effort. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, Mar 11, 2012 at 07:27:05AM -0400, Daddy wrote Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? It's my reaction to the Windows-isation and Firefox-isation of linux. So far I've managed to keep systemd and hal and dbus and pulseaudio off my machines. I agree with Linus Torvalds that linux is getting bloated and huge and scary... http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/ One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask Thanks; fixed now. I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. I have a couple of regular desktops here at home, and a desktop dedicted to my TV, plus a netbook, and a laptop. So far, I've run into only one situation where laziness on my part ends up requiring udev. The laptop has an ATI Radeon chip that requires emerging radeon-ucode. That ebuild simply dumps a bunch of binary blobs into a library folder. The kernel loads one of the binary blobs at bootup. Radeon-ucode has blobs for 2 or 3 dozen differnt Radeon GPU models. If I leave all the binary blobs in the library folder, the kernel needs udev to figure out which blob to load. But, if I leave only the correct blob for my GPU in the library folder (move/delete all the others), it loads properly without any help from udev. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On March 11, 2012 at 10:17 AM Alan McKinnon alan.mckin...@gmail.com wrote: On Sun, 11 Mar 2012 07:27:05 -0400 (EDT) Daddy da...@happypenguincomputers.com wrote: On March 11, 2012 at 5:09 AM Walter Dnes waltd...@waltdnes.org 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 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 -- Walter Dnes waltd...@waltdnes.org Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? No, it's his reaction to the fantastical amount of kitchen-sinking going on surrounding udev. Most specifically, it's the recent requirement foisted on the udev-using community to require either /usr to be part of / or to use an initramfs. Walter simply wants to show that mdev is a suitable replacement for udev in simple environments eg embedded, simple desktops without complex hotplug requirements, and servers. Canek will no doubt chip in about how this is the way things are going, it is inevitable, the boot sequence is becoming complex and various other rehashings of what's coming out of udev upstream. However, something needs to be pointed out in that regard. What udev upstream is saying is probably quite true, but only within the limits of the environment in which they work and udev is designed to handle - sophisticated desktops. The three cases I mentioned are perfectly valid use-cases, comprise a large percentage of the Linux installed base, should be catered to and have no need of the sophistication current udev aims to provide. As such, mdev is a good fit and we can add Walter to the long list of people before him who selflessly worked to make our software work better. One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. Welcome to the list, you'll soon get to know all the personalities here. We have at least one of everything - class clowns, old farts, newbies, voices of reason, influential devs and even the occasional fellow who knows what he's talking about. :-) -- Alan McKinnnon alan.mckin...@gmail.com First, my class is old fart. Though I'm always in IRC, mailing lists and forums are more my speed. story I built my first PC in
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On March 11, 2012 at 3:28 PM Walter Dnes waltd...@waltdnes.org wrote: On Sun, Mar 11, 2012 at 07:27:05AM -0400, Daddy wrote Having personally long considered Lennart Poettering a 'spawn of the devil' my question is ... is this your reaction to systemd? It's my reaction to the Windows-isation and Firefox-isation of linux. So far I've managed to keep systemd and hal and dbus and pulseaudio off my machines. I agree with Linus Torvalds that linux is getting bloated and huge and scary... http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/ We share the same opinions there. To me the Linux distros have shot their desktops in the foot; instead of getting _better_ than the competition, IMO they've actually gotten worse in the last 5 years. Will joyfully read that from Linus after my nap. (Probably did long ago and forgot it.) One minor typo to point out: /atc/portage/package.mask should be /etc/portage/package.mask Thanks; fixed now. Even when I can't offer code changes, typos are easy (having grown up in the newspaper and printing business). I just joined this list last week, but might consider sacrificing some hardware to join your endeavor if you need more testers. I have a couple of regular desktops here at home, and a desktop dedicted to my TV, plus a netbook, and a laptop. So far, I've run into only one situation where laziness on my part ends up requiring udev. The laptop has an ATI Radeon chip that requires emerging radeon-ucode. That ebuild simply dumps a bunch of binary blobs into a library folder. The kernel loads one of the binary blobs at bootup. Radeon-ucode has blobs for 2 or 3 dozen differnt Radeon GPU models. If I leave all the binary blobs in the library folder, the kernel needs udev to figure out which blob to load. But, if I leave only the correct blob for my GPU in the library folder (move/delete all the others), it loads properly without any help from udev. -- Walter Dnes waltd...@waltdnes.org iamben in #gentoo on IRC has piqued my interest to build a HTPC. Friday I put a 60G SSD and a 1TB mechanical drive on a board, partitioned the SDD, and d/led stage3 and portage before stopping. That and the earlier mentioned test machine will be my builds for tomorrow. Actually the HTPC is a strange idea, since we don't watch or even own a TV, but it might be a way to sell some of this hardware on my shelf. Kindest regards, Bruce Hill -- sig to come after punching a hole in the LAN and starting mutt on the server
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, Mar 11, 2012 at 3:37 PM, Daddy da...@happypenguincomputers.com wrote: First, my class is old fart. Though I'm always in IRC, mailing lists and forums are more my speed. [snip] Kindest regards, Bruce Hill Hi Bruce, You are cordially invited to join the Gentoo Old Timers Club [1] All the best :) David [1] http://dev.gentoo.org/~neddyseagoon/docs/oldtimers.xml -- David Abbott (dabbott)
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, 11 Mar 2012 15:37:26 -0400 (EDT) Daddy da...@happypenguincomputers.com wrote: We have spare parts so tomorrow I'll build a test machine. My Gentoo knowledge is quite limited, seeing as how we moved back after 9 years and had to start life over. But I can start by following this guide, and probably reading and learning about ebuilds. They're quite different from Slackware's build scripts, primarily due to dependency checking, etc. Once you've got the hang of building a Gentoo system from scratch, the best thing you can do is read all the man pages from portage and seeing how that compares to what's in simple ebuilds. ebuilds are quite straightforward, they all have a global section (my phrase) defining various constants, and code sections for fetching, unpacking, compiling, installing sources and the files to the live system. Quite simple in concept. The fun starts when ebuilds work fine and the dev's machine and get published, but don;t do quite the same thing on your machine :-) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, 11 Mar 2012 16:10:14 -0400 David Abbott da...@pythontoo.com wrote: On Sun, Mar 11, 2012 at 3:37 PM, Daddy da...@happypenguincomputers.com wrote: First, my class is old fart. Though I'm always in IRC, mailing lists and forums are more my speed. [snip] Kindest regards, Bruce Hill Hi Bruce, You are cordially invited to join the Gentoo Old Timers Club [1] All the best :) David [1] http://dev.gentoo.org/~neddyseagoon/docs/oldtimers.xml My mother swears blind I watched England win the World Cup but I don't remember (being only 1 year old at the time). I'm still going to call myself a members (point 5 applies) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
Alan McKinnon wrote: On Sun, 11 Mar 2012 16:10:14 -0400 David Abbott da...@pythontoo.com wrote: On Sun, Mar 11, 2012 at 3:37 PM, Daddy da...@happypenguincomputers.com wrote: First, my class is old fart. Though I'm always in IRC, mailing lists and forums are more my speed. [snip] Kindest regards, Bruce Hill Hi Bruce, You are cordially invited to join the Gentoo Old Timers Club [1] All the best :) David [1] http://dev.gentoo.org/~neddyseagoon/docs/oldtimers.xml My mother swears blind I watched England win the World Cup but I don't remember (being only 1 year old at the time). I'm still going to call myself a members (point 5 applies) Bruce, Aren't you a bit younger than me? If so, I'm a old fart too. ;-) [/Bruce] BTW folks, I have met Bruce, and family, in person and we have talked in various ways for years. We live about 75 miles apart. My lady friend ain't geeky so I can't stop by when I'm up that way, plus he moved on me again. Of course, I'm glad he moved from China and back here tho. Whew!!! Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
Correcting a typo pointed out in the earlier post today. 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 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. 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. 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 5) reboot to your new kernel. You're now running without using udev. 6) Remove udev as per the following instructions... * execute the following command at the commandline emerge --unmerge sys-fs/udev * In file /etc/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 -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On March 11, 2012 at 4:10 PM David Abbott da...@pythontoo.com wrote: On Sun, Mar 11, 2012 at 3:37 PM, Daddy da...@happypenguincomputers.com wrote: First, my class is old fart. Though I'm always in IRC, mailing lists and forums are more my speed. [snip] Kindest regards, Bruce Hill Hi Bruce, You are cordially invited to join the Gentoo Old Timers Club [1] All the best :) David [1] http://dev.gentoo.org/~neddyseagoon/docs/oldtimers.xml -- David Abbott (dabbott) Thanks, David. I remember you from LQ. I'm also usually found in ##Neddyseagoon on FreeNode. :-)}
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On March 11, 2012 at 4:27 PM Alan McKinnon alan.mckin...@gmail.com wrote: On Sun, 11 Mar 2012 15:37:26 -0400 (EDT) Daddy da...@happypenguincomputers.com wrote: We have spare parts so tomorrow I'll build a test machine. My Gentoo knowledge is quite limited, seeing as how we moved back after 9 years and had to start life over. But I can start by following this guide, and probably reading and learning about ebuilds. They're quite different from Slackware's build scripts, primarily due to dependency checking, etc. Once you've got the hang of building a Gentoo system from scratch, the best thing you can do is read all the man pages from portage and seeing how that compares to what's in simple ebuilds. ebuilds are quite straightforward, they all have a global section (my phrase) defining various constants, and code sections for fetching, unpacking, compiling, installing sources and the files to the live system. Quite simple in concept. The fun starts when ebuilds work fine and the dev's machine and get published, but don;t do quite the same thing on your machine :-) -- Alan McKinnnon alan.mckin...@gmail.com The ebuild in my local overlay that evolved from an official one has EAPI=2 But when I issue some.ebuild it has EAPI=3 on this box. And iirc another of my boxen has EAPI=4. Yes, much studying yet to be done.
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On Sun, 11 Mar 2012 19:07:37 -0400 (EDT) Daddy da...@happypenguincomputers.com wrote: On March 11, 2012 at 4:27 PM Alan McKinnon alan.mckin...@gmail.com wrote: On Sun, 11 Mar 2012 15:37:26 -0400 (EDT) Daddy da...@happypenguincomputers.com wrote: We have spare parts so tomorrow I'll build a test machine. My Gentoo knowledge is quite limited, seeing as how we moved back after 9 years and had to start life over. But I can start by following this guide, and probably reading and learning about ebuilds. They're quite different from Slackware's build scripts, primarily due to dependency checking, etc. Once you've got the hang of building a Gentoo system from scratch, the best thing you can do is read all the man pages from portage and seeing how that compares to what's in simple ebuilds. ebuilds are quite straightforward, they all have a global section (my phrase) defining various constants, and code sections for fetching, unpacking, compiling, installing sources and the files to the live system. Quite simple in concept. The fun starts when ebuilds work fine and the dev's machine and get published, but don;t do quite the same thing on your machine :-) -- Alan McKinnnon alan.mckin...@gmail.com The ebuild in my local overlay that evolved from an official one has EAPI=2 But when I issue some.ebuild it has EAPI=3 on this box. And iirc another of my boxen has EAPI=4. Yes, much studying yet to be done. Possibly you forked package-1.0 and your ebuild is still at that version. The official meanwhile has moved on to versions package-1.1 and package-1.2; those will take preference over your local ebuild regardless of precedence order of overlays (i.e. version number always wins, repo is secondary) -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
On March 11, 2012 at 5:20 PM Dale rdalek1...@gmail.com wrote: Bruce, Aren't you a bit younger than me? If so, I'm a old fart too. ;-) [/Bruce] BTW folks, I have met Bruce, and family, in person and we have talked in various ways for years. We live about 75 miles apart. My lady friend ain't geeky so I can't stop by when I'm up that way, plus he moved on me again. Of course, I'm glad he moved from China and back here tho. Whew!!! Dale In 13 days I turn 53 -- still younger than NeddySeagoon :-)}
Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5
Daddy wrote: On March 11, 2012 at 5:20 PM Dale rdalek1...@gmail.com wrote: Bruce, Aren't you a bit younger than me? If so, I'm a old fart too. ;-) [/Bruce] BTW folks, I have met Bruce, and family, in person and we have talked in various ways for years. We live about 75 miles apart. My lady friend ain't geeky so I can't stop by when I'm up that way, plus he moved on me again. Of course, I'm glad he moved from China and back here tho. Whew!!! Dale In 13 days I turn 53 -- still younger than NeddySeagoon :-)} You are older than me then. ROFL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
