[gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[waltdnes]

  After a recent thread, about udev developers wanting /usr on the same
partition as / (or else requiring initramfs), it was pretty obvious
that 90%+ of the users here strongly disliked the idea.  I went around
asking on various lists if it was possible to run Gentoo without udev.
After some research, and various unrelated delays, I've come up with a
working Gentoo without udev.  It turns out that busybox's mdev
implementation is sufficient for my needs.  I do the usual email, web
surfing, including Youtube.  I'm listening to Live365.com as I type this
email, so Flash works just fine.  Contrary to the FUD I've heard, X
works just fine, thank you, without an xorg.conf.  Modern flatscreens
with EDID info are set up automatically.  I suppose that old CRT
monitors without EDID info might require xorg.conf, but that's "exotic
hardware" nowadays.  The only change I notice is somewhat faster bootup.

  The purpose of this email is to ask adventurous people here to beta
test my approach to a udev-less Gentoo.  If we don't find any
showstopper problems, we can think about requesting Gentoo developers to
support an mdev-based profile.  It would help the cause if a large
number of testers can report that it works for them.  The instructions
for a udev-ectomy follow below.  Thanks to Zac Medico and others on the
Gentoo developers' list for their helpful hints and pointers on how to
do this.  I couldn't have figured this out by myself.

  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, there are 2 items to change

A) It appears that there may be an mdev bug in older versions of
   busybox.  To avoid that bug, keyword busybox-1.19.2 in
   /etc/portage/package.keywords  E.g. if you're using 32-bit Gentoo on
   Intel, the incantation is...

=sys-apps/busybox-1.19.2 ~x86

   Change the "~x86" to reflect your architecture, etc.

B) 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) In the bootloader append line, include "init=/sbin/linuxrc" where
   the file /sbin/linuxrc consists of *AT LEAST*...

#!/sbin/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.  If you're using lilo remember
   to re-run lilo to implement the changes.

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) ***THIS STEP IS OPTIONAL***  This is only to alay any suspicion that
   udev is still in use.  udev is pulled in by virtual/dev-manager,
   which in turn is pulled in by the kernel.
* cd /usr/portage/virtual/dev-manager
* Make a backup copy of dev-manager-0.ebuild
* Edit dev-manager-0.ebuild to include "sys-apps/busybox" as one option
  in RDEPEND, like so...

RDEPEND="|| ( sys-fs/udev
                sys-fs/devfsd
                sys-apps/busybox
                sys-fs/static-dev
                sys-freebsd/freebsd-sbin )"

  I had really wanted to use "sys-apps/busybox[mdev]", but an EAPI-0
  ebuild can't handle that syntax.

* execute the following 3 commands at the commandline
ebuild dev-manager-0.ebuild digest
emerge -1 dev-manager
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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 5044 bytes --]

On Nov 15, 2011 1:24 PM, <waltdnes@waltdnes.org> wrote:
>
>  After a recent thread, about udev developers wanting /usr on the same
> partition as / (or else requiring initramfs), it was pretty obvious
> that 90%+ of the users here strongly disliked the idea.  I went around
> asking on various lists if it was possible to run Gentoo without udev.
> After some research, and various unrelated delays, I've come up with a
> working Gentoo without udev.  It turns out that busybox's mdev
> implementation is sufficient for my needs.  I do the usual email, web
> surfing, including Youtube.  I'm listening to Live365.com as I type this
> email, so Flash works just fine.  Contrary to the FUD I've heard, X
> works just fine, thank you, without an xorg.conf.  Modern flatscreens
> with EDID info are set up automatically.  I suppose that old CRT
> monitors without EDID info might require xorg.conf, but that's "exotic
> hardware" nowadays.  The only change I notice is somewhat faster bootup.
>
>  The purpose of this email is to ask adventurous people here to beta
> test my approach to a udev-less Gentoo.  If we don't find any
> showstopper problems, we can think about requesting Gentoo developers to
> support an mdev-based profile.  It would help the cause if a large
> number of testers can report that it works for them.  The instructions
> for a udev-ectomy follow below.  Thanks to Zac Medico and others on the
> Gentoo developers' list for their helpful hints and pointers on how to
> do this.  I couldn't have figured this out by myself.
>
>  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, there are 2 items to change
>
> A) It appears that there may be an mdev bug in older versions of
>   busybox.  To avoid that bug, keyword busybox-1.19.2 in
>   /etc/portage/package.keywords  E.g. if you're using 32-bit Gentoo on
>   Intel, the incantation is...
>
> =sys-apps/busybox-1.19.2 ~x86
>
>   Change the "~x86" to reflect your architecture, etc.
>
> B) 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) In the bootloader append line, include "init=/sbin/linuxrc" where
>   the file /sbin/linuxrc consists of *AT LEAST*...
>
> #!/sbin/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.  If you're using lilo remember
>   to re-run lilo to implement the changes.
>
> 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) ***THIS STEP IS OPTIONAL***  This is only to alay any suspicion that
>   udev is still in use.  udev is pulled in by virtual/dev-manager,
>   which in turn is pulled in by the kernel.
> * cd /usr/portage/virtual/dev-manager
> * Make a backup copy of dev-manager-0.ebuild
> * Edit dev-manager-0.ebuild to include "sys-apps/busybox" as one option
>  in RDEPEND, like so...
>
> RDEPEND="|| ( sys-fs/udev
>                sys-fs/devfsd
>                sys-apps/busybox
>                sys-fs/static-dev
>                sys-freebsd/freebsd-sbin )"
>
>  I had really wanted to use "sys-apps/busybox[mdev]", but an EAPI-0
>  ebuild can't handle that syntax.
>
> * execute the following 3 commands at the commandline
> ebuild dev-manager-0.ebuild digest
> emerge -1 dev-manager
> 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
>

Sounds nice!

However, my Gentoo systems are all virtual servers (DomU VMs on XenServer).
So, the hardware devices are static. Will switching over to mdev give any
benefits?

I even am toying around with the idea of having a completely static /dev,
but still can't find any guide/pointers yet.

(Apologies if my email is OOT)

Rgds,

[-- Attachment #2: Type: text/html, Size: 6398 bytes --]

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Alan McKinnon]

On Tue, 15 Nov 2011 14:44:58 +0700
Pandu Poluan <pandu@poluan.info> wrote:

> >  Create the file if it doesn't already exist.  You now have a
> > totally udev-free machine
> >
> 
> Sounds nice!
> 
> However, my Gentoo systems are all virtual servers (DomU VMs on
> XenServer). So, the hardware devices are static. Will switching over
> to mdev give any benefits?
> 
> I even am toying around with the idea of having a completely
> static /dev, but still can't find any guide/pointers yet.
> 
> (Apologies if my email is OOT)
> 

A VM can be surprisingly useful for this. If you can emulate different
hardware you can generate useful testing scenarios quickly. The tests
won't be conclusive (emulated hardware is not the same thing as real
hardware) but you *can* test to a standard. 

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

On Nov 15, 2011 11:19 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Tue, 15 Nov 2011 14:44:58 +0700
> Pandu Poluan <pandu@poluan.info> wrote:
>
> > >  Create the file if it doesn't already exist.  You now have a
> > > totally udev-free machine
> > >
> >
> > Sounds nice!
> >
> > However, my Gentoo systems are all virtual servers (DomU VMs on
> > XenServer). So, the hardware devices are static. Will switching over
> > to mdev give any benefits?
> >
> > I even am toying around with the idea of having a completely
> > static /dev, but still can't find any guide/pointers yet.
> >
> > (Apologies if my email is OOT)
> >
>
> A VM can be surprisingly useful for this. If you can emulate different
> hardware you can generate useful testing scenarios quickly. The tests
> won't be conclusive (emulated hardware is not the same thing as real
> hardware) but you *can* test to a standard.
>

True. Unfortunately, I don't have 'exotic' hardware to test mdev against,
and USB pass-through is not yet supported on XenServer 5.6 (which I'm using
right now).

I can try it inside VirtualBox on my Windows workstation though. Will that
help?

Rgds,

[-- Attachment #2: Type: text/html, Size: 1584 bytes --]

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Albert W. Hopkins]

On Tue, 2011-11-15 at 14:44 +0700, Pandu Poluan wrote:
> However, my Gentoo systems are all virtual servers (DomU VMs on
> XenServer).
> So, the hardware devices are static. Will switching over to mdev give
> any
> benefits?
> 
> I even am toying around with the idea of having a completely
> static /dev,
> but still can't find any guide/pointers yet.

I have a completely static /dev/ on my VMs.. I just disable the udev
devfs services and create whatever device nodes needed manually.

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Nov 15, 2011 11:43 PM, "Albert W. Hopkins" <marduk@letterboxes.org>
wrote:
>
> On Tue, 2011-11-15 at 14:44 +0700, Pandu Poluan wrote:
> > However, my Gentoo systems are all virtual servers (DomU VMs on
> > XenServer).
> > So, the hardware devices are static. Will switching over to mdev give
> > any
> > benefits?
> >
> > I even am toying around with the idea of having a completely
> > static /dev,
> > but still can't find any guide/pointers yet.
>
> I have a completely static /dev/ on my VMs.. I just disable the udev
> devfs services and create whatever device nodes needed manually.
>

Ah, thanks! Now I have more confidence to experiment, knowing someone else
have successfully went the static /dev road :-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 951 bytes --]

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[waltdnes]

On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote

> However, my Gentoo systems are all virtual servers (DomU VMs on XenServer).
> So, the hardware devices are static. Will switching over to mdev give any
> benefits?
> 
> I even am toying around with the idea of having a completely static /dev,
> but still can't find any guide/pointers yet.
> 
> (Apologies if my email is OOT)

  The more scenarios we can test, the better.  mdev might shave a second
  or two off the VM's bootup time, versus udev.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Nov 16, 2011 3:21 AM, <waltdnes@waltdnes.org> wrote:
>
> On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote
>
> > However, my Gentoo systems are all virtual servers (DomU VMs on
XenServer).
> > So, the hardware devices are static. Will switching over to mdev give
any
> > benefits?
> >
> > I even am toying around with the idea of having a completely static
/dev,
> > but still can't find any guide/pointers yet.
> >
> > (Apologies if my email is OOT)
>
>  The more scenarios we can test, the better.  mdev might shave a second
>  or two off the VM's bootup time, versus udev.
>

Okay, I have two staging VMs on XenServer and one on VMware. I'm going to
report back what happens. If anything bad happens, *should* be an easy
rollback to the previous snapshot.

Rgds,

[-- Attachment #2: Type: text/html, Size: 1022 bytes --]

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

Plus, I'm feeling adventurous and will experiment with VirtualBox also ;)

Rgds,
 On Nov 16, 2011 7:52 AM, "Pandu Poluan" <pandu@poluan.info> wrote:

>
> On Nov 16, 2011 3:21 AM, <waltdnes@waltdnes.org> wrote:
> >
> > On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote
> >
> > > However, my Gentoo systems are all virtual servers (DomU VMs on
> XenServer).
> > > So, the hardware devices are static. Will switching over to mdev give
> any
> > > benefits?
> > >
> > > I even am toying around with the idea of having a completely static
> /dev,
> > > but still can't find any guide/pointers yet.
> > >
> > > (Apologies if my email is OOT)
> >
> >  The more scenarios we can test, the better.  mdev might shave a second
> >  or two off the VM's bootup time, versus udev.
> >
>
> Okay, I have two staging VMs on XenServer and one on VMware. I'm going to
> report back what happens. If anything bad happens, *should* be an easy
> rollback to the previous snapshot.
>
> Rgds,
>

[-- Attachment #2: Type: text/html, Size: 1438 bytes --]

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[yegle]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

I'm using systemd as init. Currently there's no .service file for mdev.
Hope someone on this list can provide one :-)

On Wed, Nov 16, 2011 at 9:41 AM, Pandu Poluan <pandu@poluan.info> wrote:

> Plus, I'm feeling adventurous and will experiment with VirtualBox also ;)
>
> Rgds,
>  On Nov 16, 2011 7:52 AM, "Pandu Poluan" <pandu@poluan.info> wrote:
>
>>
>> On Nov 16, 2011 3:21 AM, <waltdnes@waltdnes.org> wrote:
>> >
>> > On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote
>> >
>> > > However, my Gentoo systems are all virtual servers (DomU VMs on
>> XenServer).
>> > > So, the hardware devices are static. Will switching over to mdev give
>> any
>> > > benefits?
>> > >
>> > > I even am toying around with the idea of having a completely static
>> /dev,
>> > > but still can't find any guide/pointers yet.
>> > >
>> > > (Apologies if my email is OOT)
>> >
>> >  The more scenarios we can test, the better.  mdev might shave a second
>> >  or two off the VM's bootup time, versus udev.
>> >
>>
>> Okay, I have two staging VMs on XenServer and one on VMware. I'm going to
>> report back what happens. If anything bad happens, *should* be an easy
>> rollback to the previous snapshot.
>>
>> Rgds,
>>
>

[-- Attachment #2: Type: text/html, Size: 1929 bytes --]

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Pandu Poluan]

On Wed, Nov 16, 2011 at 07:52, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Nov 16, 2011 3:21 AM, <waltdnes@waltdnes.org> wrote:
>>
>>  The more scenarios we can test, the better.  mdev might shave a second
>>  or two off the VM's bootup time, versus udev.
>>
>
> Okay, I have two staging VMs on XenServer and one on VMware. I'm going to
> report back what happens. If anything bad happens, *should* be an easy
> rollback to the previous snapshot.
>

1st Report: amd64-hardened on XenServer, PV-mode

Booted okay. There's 1 (one) red asterisk but it booted so fast I
can't see what that asterisk was about. `less /var/log/rc.log` did not
show anything...

... but I realized that I can scroll up on XenServer console, so I saw
that the asterisk said:

* Error: fopen(/lib64/rc/init.d/rc.log) failed: No such file or directory

Nothing serious though. I think it was because /lib64/rc/init.d got
overlaid by rc-svcdir during boot, so rc.log disappeared.

(Doing `mount -o bind / /mnt/rooot && ls /mnt/rooot/lib64/rc/init.d`
showed that rc.log existed in the non-overlaid /lib64/rc/init.d)

/dev/xvdb* (which was not created statically in the non-overlaid /dev) appeared.

/dev/xvdd appeared when I attached an ISO image to the VM.

mount /dev/xvdd /mnt/cd worked. I could `ls /mnt/cd` and see the
contents of the CD.

"Ejecting" the ISO image made /dev/xvdd disappear (as it should).

Networking is okay.

The Xen virtual console (hvc0) works okay.

`rc-update | grep dev` showed `udev-postmount` still part of default,
so I did `rc-update del udev-postmount default` and rebooted, and all
were still well (and still a glint of red asterisk).

Unmerging udev went well.

All in all, rebooting after switching to udev *seems* to be faster.

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[Pandu Poluan]

On Wed, Nov 16, 2011 at 07:52, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Nov 16, 2011 3:21 AM, <waltdnes@waltdnes.org> wrote:
>>
>>  The more scenarios we can test, the better.  mdev might shave a second
>>  or two off the VM's bootup time, versus udev.
>>
>
> Okay, I have two staging VMs on XenServer and one on VMware. I'm going to
> report back what happens. If anything bad happens, *should* be an easy
> rollback to the previous snapshot.
>

2nd Report: amd64-hardened on VMware, using VMware PVSCSI for hard
disk, but e1000 for network.

Booted okay, and similar to the report on XenServer. But this time. I
got 2 (two) red asterisks during boot. The 1st one seems to say "Error
... read-only file system". The second starts with "Warning temp file
left behind ..." (or something similar)

`rc-update del udev-postmount default && reboot` ... no problem.

Unmerged udev && reboot ... no problem.


There. No problem with XenServer and/or VMware. Except for the 1 or 2
red asterisks during boot (which I'm not sure caused by udev-->mdev
switch or something else).


I'll experiment with VirtualBox (on Windows) tomorrow. This might be
much more interesting :-)


Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?

[pk]

On 2011-11-15 07:21, waltdnes@waltdnes.org wrote:

>   The purpose of this email is to ask adventurous people here to beta
> test my approach to a udev-less Gentoo.  If we don't find any
> showstopper problems, we can think about requesting Gentoo developers to
> support an mdev-based profile.  It would help the cause if a large
> number of testers can report that it works for them.  The instructions
> for a udev-ectomy follow below.  Thanks to Zac Medico and others on the
> Gentoo developers' list for their helpful hints and pointers on how to
> do this.  I couldn't have figured this out by myself.

I apologize for not having replied sooner. This sounds very interesting
and I will try this out, when I can find the time to "tinker". Thanks
for doing this!

Best regards

Peter K

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 2

[waltdnes]

  Based on feedback, I've changed step 6, to get a modified ebuild for
virtual/dev-manager to properly check for busybox with the "mdev" USE
flag.  Steps 1-through-5 are unchanged.

  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, there are 2 items to change

A) It appears that there may be an mdev bug in older versions of
   busybox.  To avoid that bug, keyword busybox-1.19.2 in
   /etc/portage/package.keywords  E.g. if you're using 32-bit Gentoo on
   Intel, the incantation is...

=sys-apps/busybox-1.19.2 ~x86

   Change the "~x86" to reflect your architecture, etc.

B) 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) In the bootloader append line, include "init=/sbin/linuxrc" where
   the file /sbin/linuxrc consists of *AT LEAST*...

#!/sbin/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.  If you're using lilo remember
   to re-run lilo to implement the changes.

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) ***THIS STEP IS OPTIONAL***  This is only to alay any suspicion that
   udev is still in use.  udev is pulled in by virtual/dev-manager,
   which in turn is pulled in by the kernel.

* If you don't already have an overlay, create one, and implement it in
  /etc/make.conf.  In the following example, I'll use my setup, which has
  the overlay in /usr/local/portage

* copy the contents of /usr/portage/virtual/dev-manager/ to
  /usr/local/portage/virtual/dev-manager/

* cd /usr/local/portage/virtual/dev-manager/

* Edit the dev-manager-0.ebuild in the overlay to include
  "sys-apps/busybox[mdev]" as one option in RDEPEND.  And also include
  "EAPI=2" at the top of the ebuild, which is required for this syntax.
  The revised ebuild is shown below.

############################################
EAPI=2

DESCRIPTION="Virtual for the device filesystem manager"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~spar
c-fbsd ~x86-fbsd"
IUSE=""

DEPEND=""
RDEPEND="|| ( sys-fs/udev
                sys-apps/busybox[mdev]
                sys-fs/devfsd
                sys-fs/static-dev
                sys-freebsd/freebsd-sbin )"
############################################

* execute the following 3 commands at the commandline
ebuild dev-manager-0.ebuild digest
emerge -1 dev-manager
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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 2

[Pandu Poluan]

On Mon, Nov 21, 2011 at 17:47,  <waltdnes@waltdnes.org> wrote:
>

----- >8 snip

> 3) In the bootloader append line, include "init=/sbin/linuxrc" where
>   the file /sbin/linuxrc consists of *AT LEAST*...
>
> #!/sbin/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.  If you're using lilo remember
>   to re-run lilo to implement the changes.
>

----- >8 snip

BTW, "which busybox" returns /bin/busybox instead of /sbin/busybox

In other words, all this time /sbin/linuxrc *didn't* run on my boxen,
but the kernel is smart enough to "run with the defaults", whatever
that is (I forgot to write down the exact error message in dmesg).

After fixing the hashbang line, I can now insert the line "mount -o
remount,rw /" at the 2nd line...

... and I no longer have the two red asterisks! Yay!!

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 2

[Walter Dnes]

On Wed, Nov 30, 2011 at 08:58:13PM +0700, Pandu Poluan wrote
> On Mon, Nov 21, 2011 at 17:47,  <waltdnes@waltdnes.org> wrote:
> >
> 
> ----- >8 snip
> 
> > 3) In the bootloader append line, include "init=/sbin/linuxrc" where
> > ?? the file /sbin/linuxrc consists of *AT LEAST*...
> >
> > #!/sbin/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. ??If you're using lilo remember
> > ?? to re-run lilo to implement the changes.
> >
> 
> ----- >8 snip
> 
> BTW, "which busybox" returns /bin/busybox instead of /sbin/busybox

  In plain English... I goofed.  It is /bin/busybox.  Thanks for
catching that.  This is what beta testing is for <G>.  I'll update the
instructions.

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Walter Dnes]

 Corrected "#!/sbin/busybox ash" to "#!/bin/busybox ash" in step 3.  The
weird part is that my system actually booted and ran fine even with this
typo in the script.
 
  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, there are 2 items to change

A) It appears that there may be an mdev bug in older versions of
   busybox.  To avoid that bug, keyword busybox-1.19.2 in
   /etc/portage/package.keywords  E.g. if you're using 32-bit Gentoo on
   Intel, the incantation is...

=sys-apps/busybox-1.19.2 ~x86

   Change the "~x86" to reflect your architecture, etc.

B) 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) In the bootloader append line, include "init=/sbin/linuxrc" where
   the file /sbin/linuxrc consists of *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.  If you're using lilo remember
   to re-run lilo to implement the changes.

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) ***THIS STEP IS OPTIONAL***  This is only to alay any suspicion that
   udev is still in use.  udev is pulled in by virtual/dev-manager,
   which in turn is pulled in by the kernel.

* If you don't already have an overlay, create one, and implement it in
  /etc/make.conf.  In the following example, I'll use my setup, which has
  the overlay in /usr/local/portage

* copy the contents of /usr/portage/virtual/dev-manager/ to
  /usr/local/portage/virtual/dev-manager/

* cd /usr/local/portage/virtual/dev-manager/

* Edit the dev-manager-0.ebuild in the overlay to include
  "sys-apps/busybox[mdev]" as one option in RDEPEND.  And also include
  "EAPI=2" at the top of the ebuild, which is required for this syntax.
  The revised ebuild is shown below.

############################################
EAPI=2

DESCRIPTION="Virtual for the device filesystem manager"
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 ~spar
c-fbsd ~x86-fbsd"
IUSE=""

DEPEND=""
RDEPEND="|| ( sys-fs/udev
                sys-apps/busybox[mdev]
                sys-fs/devfsd
                sys-fs/static-dev
                sys-freebsd/freebsd-sbin )"
############################################

* execute the following 3 commands at the commandline
ebuild dev-manager-0.ebuild digest
emerge -1 dev-manager
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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

On Dec 2, 2011 2:50 AM, "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
>  Corrected "#!/sbin/busybox ash" to "#!/bin/busybox ash" in step 3.  The
> weird part is that my system actually booted and ran fine even with this
> typo in the script.
>

Amazingly enough, my system also works. Albeit with two red asterisks
during boot. But the errors only affected rc logging, so I didn't pursue
the issue further. Then again, I don't need to do smarty exotic things in
/sbin/linuxrc, so the kernel's default actions of automagically mounting
/proc and /sys saved my posterior ;-)

The only thing left for me now is to figure out how the hey rc logging
perform logging while root is still ro. I currently have suppressed the red
asterisks by remounting root rw in /sbin/linuxrc, but am thinking of
reverting that because fsck won't work. Yes, the fsck can be performed
inside /sbin/linuxrc, but I rather not do that to keep /sbin/linuxrc
simple.

Am going to parse the initscripts later today to figure things out.

Rgds,

[-- Attachment #2: Type: text/html, Size: 1208 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Walter Dnes]

  In the instructions here, I've set up a revised dev-manager ebuild in
an overlay.  I've requested the changes to be incorporated into the
official ebuild and it appears to have been accepted.  See...

https://bugs.gentoo.org/show_bug.cgi?id=395319

It should be rolled out eventually, and the overlay won't be necessary.

  I think I've found one item so far that requires udev.  My laptop's
graphics chip needs a binary blob from radeon-ucode.  That binary blob,
in turn, requires the presence of /usr/lib/libudev.so.0 which is a
symlink to /usr/lib/libudev.so.0.9.3 (which is also required).  I can

emerge udev
move or copy the 2 files over to /root
unmerge udev
move or copy the 2 files from /root to /usr/lib/

and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
64-bit gentoo.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

On Tue, Jan 3, 2012 at 17:04, Walter Dnes <waltdnes@waltdnes.org> wrote:
>  In the instructions here, I've set up a revised dev-manager ebuild in
> an overlay.  I've requested the changes to be incorporated into the
> official ebuild and it appears to have been accepted.  See...
>
> https://bugs.gentoo.org/show_bug.cgi?id=395319
>
> It should be rolled out eventually, and the overlay won't be necessary.
>

Cool! :D

>  I think I've found one item so far that requires udev.  My laptop's
> graphics chip needs a binary blob from radeon-ucode.  That binary blob,
> in turn, requires the presence of /usr/lib/libudev.so.0 which is a
> symlink to /usr/lib/libudev.so.0.9.3 (which is also required).  I can
>
> emerge udev
> move or copy the 2 files over to /root
> unmerge udev
> move or copy the 2 files from /root to /usr/lib/
>
> and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
> 64-bit gentoo.
>

Well it doesn't need udev itself, just libudev.

But if the binary blob is hard-coded to search for
/usr/lib/libudev.so.0{,.9.3}, that means /usr must exist at
boot-time...

... or at least /usr/lib/libudev.so.0{,.9.3}

IMO, providing 1 file (+ 1 symlink) is still much better than having
to provide the *whole* /usr tree during boot-time.

Now, what's needed is to "catalog" (1) essential boot-time devs that
can't be handled by mdev, and (2) essential files that need to exist
under /usr during boot-time.

#1 should be interesting for busybox upstream, while #2 will be
necessary for those trying to wean themselves off udev :-)

We're one step closer to an udev-free Gentoo, yay!

(Come to think of it, has *any* distro ever attempted this...
'unconventional of going udev-free?)

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

The 03/01/12, Pandu Poluan wrote:

> (Come to think of it, has *any* distro ever attempted this...
> 'unconventional of going udev-free?)

mdev is not an udev replacement. It's a very minimalist udev designed
for embedded systems and initramfs. These days, a full-featured system
require a dynamic /dev and AFAIK the only existing and up-to-date tool
for this job is udev.

I don't think any other distro attempted to get free of udev as it means
coming back to 10 years ago, at least.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Jan 3, 2012 7:35 PM, "Nicolas Sebrecht" <nsebrecht@piing.fr> wrote:
>
> The 03/01/12, Pandu Poluan wrote:
>
> > (Come to think of it, has *any* distro ever attempted this...
> > 'unconventional of going udev-free?)
>
> mdev is not an udev replacement. It's a very minimalist udev designed
> for embedded systems and initramfs. These days, a full-featured system
> require a dynamic /dev and AFAIK the only existing and up-to-date tool
> for this job is udev.
>
> I don't think any other distro attempted to get free of udev as it means
> coming back to 10 years ago, at least.
>

For desktops, I agree.

But I can see a use case for mdev completely replacing udev: servers and
virtual machines.

Servers, especially production ones, have a hardware change only once in
every two blue moons. They don't need all the bells and whistles of udev.

Even more so when you've gone the virtualized route.

Since servers are arguably where Linux shines the most, mdev should be
seriously considered as a udev replacement.

Rgds,

[-- Attachment #2: Type: text/html, Size: 1256 bytes --]

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

The 03/01/12, Pandu Poluan wrote:

>    But I can see a use case for mdev completely replacing udev: servers and
>    virtual machines.
> 
>    Servers, especially production ones, have a hardware change only once in
>    every two blue moons. They don't need all the bells and whistles of udev.
> 
>    Even more so when you've gone the virtualized route.
> 
>    Since servers are arguably where Linux shines the most, mdev should be
>    seriously considered as a udev replacement.

But servers have enough ressources to run udev and any required
initramfs to mount /usr.

So, the question is where engineering should go:

- mdev and manually manage /dev devices if nedded

or

- rely on initramfs to mount /usr.

As initramfs is a prooven working solution, all distributions I know use
it either by default or if needed.

Also, I think the coming problem you will be face with in the mdev way
is the move of binaries from /bin to /usr/bin and so.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 03/01/12, Pandu Poluan wrote:
>
>>    But I can see a use case for mdev completely replacing udev: servers and
>>    virtual machines.
>>
>>    Servers, especially production ones, have a hardware change only once in
>>    every two blue moons. They don't need all the bells and whistles of udev.
>>
>>    Even more so when you've gone the virtualized route.
>>
>>    Since servers are arguably where Linux shines the most, mdev should be
>>    seriously considered as a udev replacement.
>
> But servers have enough ressources to run udev and any required
> initramfs to mount /usr.
>

No, no, no, you got it the wrong way around.

It's not udev *per se* that I -- as a server admin -- want to get rid of.

It's the initramfs.

And I also want to put /usr in a separate partition.

The problem is that, judging from where udev is going in upstream, we
will be forced to use initramfs, or put /usr in /

By migrating from udev to mdev, I am no longer forced to do either.

> So, the question is where engineering should go:
>
> - mdev and manually manage /dev devices if nedded
>
> or
>
> - rely on initramfs to mount /usr.
>

As a SysAdmin, I'd prever the 1st one, thank you.

Adding hardware to server is a MAJOR event, something worthy of
sacrificing some goats and lambs to appease the Information Gods and
Goddesses.

And after the new shiny thing gets installed physically, it will be
followed up -- with 109% certainty -- with some configuration in the
OS.

> As initramfs is a prooven working solution, all distributions I know use
> it either by default or if needed.
>

Then again, using initramfs is yet-another-component waiting to break.

Knowing Murphy's Law, it will one day fuck up everything.

> Also, I think the coming problem you will be face with in the mdev way
> is the move of binaries from /bin to /usr/bin and so.
>

Again, on a server, this will be a one-time affair.

I can always bind-mount the /usr of / under /mnt, letting the "/usr"
get overlaid by the /usr partition. If there's a piece of hardware
that needs a piece of binary inside /usr, I'll just cp that binary
into /mnt/usr/whatever to appease that piece of hardware.

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

The 03/01/12, Pandu Poluan wrote:
> On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

> > But servers have enough ressources to run udev and any required
> > initramfs to mount /usr.
> 
> No, no, no, you got it the wrong way around.
> 
> It's not udev *per se* that I -- as a server admin -- want to get rid of.
> 
> It's the initramfs.
> 
> And I also want to put /usr in a separate partition.
> 
> The problem is that, judging from where udev is going in upstream, we
> will be forced to use initramfs, or put /usr in /

I know. It's the "I want to get the rid of initramfs" thing that looks
crazy to me.

> > As initramfs is a prooven working solution, all distributions I know use
> > it either by default or if needed.
> 
> Then again, using initramfs is yet-another-component waiting to break.
> 
> Knowing Murphy's Law, it will one day fuck up everything.

And the mdev alternative won't follow this law?

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Tue, 3 Jan 2012 15:31:20 +0100
Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

> > Then again, using initramfs is yet-another-component waiting to
> > break.
> > 
> > Knowing Murphy's Law, it will one day fuck up everything.  
> 
> And the mdev alternative won't follow this law?


It's not immune to it, just statistically less likely to be affected.

mdev sans initramfs is a less complex solution than udev plus
initramfs. Ergo, all other things being equal, less bits to break.

 

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

Alan McKinnon wrote:
> On Tue, 3 Jan 2012 15:31:20 +0100
> Nicolas Sebrecht<nsebrecht@piing.fr>  wrote:
>
>>> Then again, using initramfs is yet-another-component waiting to
>>> break.
>>>
>>> Knowing Murphy's Law, it will one day fuck up everything.
>> And the mdev alternative won't follow this law?
>
> It's not immune to it, just statistically less likely to be affected.
>
> mdev sans initramfs is a less complex solution than udev plus
> initramfs. Ergo, all other things being equal, less bits to break.
>
>

Yep.  I *think* I got a init thingy to work but I'm still not sure and 
apparently since there was no replies to my other thread, no one else 
knows either.  From the messages in dmesg, it looks like I have tho.  
Thing is, if I reboot and the init fails, I have no real clue how to fix 
it.  I know this because I ran into this same thing on Mandriva, along 
with the dependency problems that is well known.  The fact that Gentoo 
has a simple booting process is what really got me interested in 
Gentoo.  If we are going down this road, I may check and see if the 
dependency problems are fixed.  As bad as it is to say, Gentoo is 
getting more like other distros that I left or didn't want to bother 
with.  Makes me wonder.  I know I am a unique old bird but I bet I am 
not alone in this.

It sort of comes down to this, if I can't boot because of a broken 
init*, I may just save my /home and data drive and install something else.

Just my $0.02 worth and it ain't worth more than that I'm sure.

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:

> I know. It's the "I want to get the rid of initramfs" thing that looks
> crazy to me.

No one is saying they want to get rid of the initramfs, because they are
not using one. What people object to is being forced to start using one.


-- 
Neil Bothwick

"An investment in knowledge always pays the best interest." - Benjamin
Franklin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

Neil Bothwick wrote:
> On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:
>
>> I know. It's the "I want to get the rid of initramfs" thing that looks
>> crazy to me.
> No one is saying they want to get rid of the initramfs, because they are
> not using one. What people object to is being forced to start using one.
>
>

You got that right.  I have not used one since I started using Gentoo.  
Now, I may very well have to start.  I hope mdev gets to a point where 
it works really well on desktop systems.

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Jan 4, 2012 6:19 AM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Neil Bothwick wrote:
>>
>> On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:
>>
>>> I know. It's the "I want to get the rid of initramfs" thing that looks
>>> crazy to me.
>>
>> No one is saying they want to get rid of the initramfs, because they are
>> not using one. What people object to is being forced to start using one.
>>
>>
>
> You got that right.  I have not used one since I started using Gentoo.
 Now, I may very well have to start.  I hope mdev gets to a point where it
works really well on desktop systems.
>

You were there in the thread linked by Walt, udev is just one of several
packages maintained by RH people that *demands* /usr to be mounted during
boot.

And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin...

I'm getting depressed. One battle might be won (mdev vs udev), but there's
still a war against the RH braindeadness...

Rgds,

[-- Attachment #2: Type: text/html, Size: 1234 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Canek Peláez Valdés]

On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Jan 4, 2012 6:19 AM, "Dale" <rdalek1967@gmail.com> wrote:
>>
>> Neil Bothwick wrote:
>>>
>>> On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:
>>>
>>>> I know. It's the "I want to get the rid of initramfs" thing that looks
>>>> crazy to me.
>>>
>>> No one is saying they want to get rid of the initramfs, because they are
>>> not using one. What people object to is being forced to start using one.
>>>
>>>
>>
>> You got that right.  I have not used one since I started using Gentoo.
>>  Now, I may very well have to start.  I hope mdev gets to a point where it
>> works really well on desktop systems.
>>
>
> You were there in the thread linked by Walt, udev is just one of several
> packages maintained by RH people that *demands* /usr to be mounted during
> boot.
>
> And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin...
>
> I'm getting depressed. One battle might be won (mdev vs udev), but there's
> still a war against the RH braindeadness...

I'm sorry to tell you this, but (as admirable as it could be), the
mdev hack to use it instead of udev is not a "victory". We are not at
war, in the first place; and in the second place, the mdev hack would
be used by a handful of guys bent on refusing a change that, like it
or not, would in the end come. Like Gentoo on FreeBSD, it would be a
nice hack, maybe even worthy of applause, but in the end irrelevant: a
toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy
nonetheless.

The heavy development will continue to happen in udev, and the devices
that will dominate in the future (touchscreens, bluetooth input and
audio devices, hardware that has a highly dynamic change rate) will
only be supported by udev. The mdev hack will be useful maybe to only
some guys, and even then udev would be able to do the same (and more).

The use of an initramfs (or, alternatively, having /usr in the same
partition as /), and maybe the move of /bin to /usr/bin and /lib to
/usr/lib will be made, and in the future most of the interesting
software will simply assume that this is how a system works. Maybe we
will even stop to use the ridiculous short directory names from the
stone age, and we will start using sensible names:

/usr -> /System
/etc -> /Config
/var -> /Variable

I feel a deep respect for the people working on making mdev a
"replacement" of udev; it is not an easy task (even if it only works
for a really small subset of the use cases udev covers), and something
that I certainly would never do. But their hack (as beautiful as it
may be) will never be used by the majority of Linux users, and
probably not even by the majority of Gentoo users (if my
interpretation of the discussion on gentoo-dev is correct). And with
the pass of time it will be harder and harder to keep the hack working
with new hardware, new software, and new use cases.

But, hey, this is FOSS; you guys go nuts hacking in whatever feature
(or anti-feature) you like. As in the case of this mdev hack, it may
even be included in the Gentoo ebuilds. Just don't expect it to be
supported forever, don't expect it to support general-purpose setups,
and certainly don't call it "a victory". It's just the same history as
always: the people writing the code are the ones calling the shots.

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

Canek Peláez Valdés wrote:
> On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan<pandu@poluan.info>  wrote:
>> On Jan 4, 2012 6:19 AM, "Dale"<rdalek1967@gmail.com>  wrote:
>>> Neil Bothwick wrote:
>>>> On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:
>>>>
>>>>> I know. It's the "I want to get the rid of initramfs" thing that looks
>>>>> crazy to me.
>>>> No one is saying they want to get rid of the initramfs, because they are
>>>> not using one. What people object to is being forced to start using one.
>>>>
>>>>
>>> You got that right.  I have not used one since I started using Gentoo.
>>>   Now, I may very well have to start.  I hope mdev gets to a point where it
>>> works really well on desktop systems.
>>>
>> You were there in the thread linked by Walt, udev is just one of several
>> packages maintained by RH people that *demands* /usr to be mounted during
>> boot.
>>
>> And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin...
>>
>> I'm getting depressed. One battle might be won (mdev vs udev), but there's
>> still a war against the RH braindeadness...
> I'm sorry to tell you this, but (as admirable as it could be), the
> mdev hack to use it instead of udev is not a "victory". We are not at
> war, in the first place; and in the second place, the mdev hack would
> be used by a handful of guys bent on refusing a change that, like it
> or not, would in the end come. Like Gentoo on FreeBSD, it would be a
> nice hack, maybe even worthy of applause, but in the end irrelevant: a
> toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy
> nonetheless.
>
> The heavy development will continue to happen in udev, and the devices
> that will dominate in the future (touchscreens, bluetooth input and
> audio devices, hardware that has a highly dynamic change rate) will
> only be supported by udev. The mdev hack will be useful maybe to only
> some guys, and even then udev would be able to do the same (and more).
>
> The use of an initramfs (or, alternatively, having /usr in the same
> partition as /), and maybe the move of /bin to /usr/bin and /lib to
> /usr/lib will be made, and in the future most of the interesting
> software will simply assume that this is how a system works. Maybe we
> will even stop to use the ridiculous short directory names from the
> stone age, and we will start using sensible names:
>
> /usr ->  /System
> /etc ->  /Config
> /var ->  /Variable
>
> I feel a deep respect for the people working on making mdev a
> "replacement" of udev; it is not an easy task (even if it only works
> for a really small subset of the use cases udev covers), and something
> that I certainly would never do. But their hack (as beautiful as it
> may be) will never be used by the majority of Linux users, and
> probably not even by the majority of Gentoo users (if my
> interpretation of the discussion on gentoo-dev is correct). And with
> the pass of time it will be harder and harder to keep the hack working
> with new hardware, new software, and new use cases.
>
> But, hey, this is FOSS; you guys go nuts hacking in whatever feature
> (or anti-feature) you like. As in the case of this mdev hack, it may
> even be included in the Gentoo ebuilds. Just don't expect it to be
> supported forever, don't expect it to support general-purpose setups,
> and certainly don't call it "a victory". It's just the same history as
> always: the people writing the code are the ones calling the shots.
>
> Regards.

I wonder how many times this has been said about other software that is 
now in wide spread use.  Keep in mind, some people think Gentoo is dying 
and has been dying for YEARS.  That's not just one package but a whole 
distro.

Will mdev replace udev, I dunno.  Thing is, you don't know that it won't 
either.  Someone could come along and help Walter and make it better 
than udev ever dreamed of being.

I just have to mention hal too.  Lots of people thought that was the new 
sliced bread and frozen pizza.  It sure did fall hard tho.

As I said about my ex once, time tells.  Sometimes, time is the only 
thing that does tell too.  Reminds me of wine although I don't drink it.

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[Michael Mol]

On Wed, Jan 4, 2012 at 6:33 PM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>>
>> On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan<pandu@poluan.info>  wrote:
>>>
>>> On Jan 4, 2012 6:19 AM, "Dale"<rdalek1967@gmail.com>  wrote:
>>>>
>>>> Neil Bothwick wrote:
>>>>>
>>>>> On Tue, 3 Jan 2012 15:31:20 +0100, Nicolas Sebrecht wrote:
>>>>>
>>>>>> I know. It's the "I want to get the rid of initramfs" thing that looks
>>>>>> crazy to me.
>>>>>
>>>>> No one is saying they want to get rid of the initramfs, because they
>>>>> are
>>>>> not using one. What people object to is being forced to start using
>>>>> one.
>>>>>
>>>>>
>>>> You got that right.  I have not used one since I started using Gentoo.
>>>>  Now, I may very well have to start.  I hope mdev gets to a point where
>>>> it
>>>> works really well on desktop systems.
>>>>
>>> You were there in the thread linked by Walt, udev is just one of several
>>> packages maintained by RH people that *demands* /usr to be mounted during
>>> boot.
>>>
>>> And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin...
>>>
>>> I'm getting depressed. One battle might be won (mdev vs udev), but
>>> there's
>>> still a war against the RH braindeadness...
>>
>> I'm sorry to tell you this, but (as admirable as it could be), the
>> mdev hack to use it instead of udev is not a "victory". We are not at
>> war, in the first place; and in the second place, the mdev hack would
>> be used by a handful of guys bent on refusing a change that, like it
>> or not, would in the end come. Like Gentoo on FreeBSD, it would be a
>> nice hack, maybe even worthy of applause, but in the end irrelevant: a
>> toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy
>> nonetheless.
>>
>> The heavy development will continue to happen in udev, and the devices
>> that will dominate in the future (touchscreens, bluetooth input and
>> audio devices, hardware that has a highly dynamic change rate) will
>> only be supported by udev. The mdev hack will be useful maybe to only
>> some guys, and even then udev would be able to do the same (and more).
>>
>> The use of an initramfs (or, alternatively, having /usr in the same
>> partition as /), and maybe the move of /bin to /usr/bin and /lib to
>> /usr/lib will be made, and in the future most of the interesting
>> software will simply assume that this is how a system works. Maybe we
>> will even stop to use the ridiculous short directory names from the
>> stone age, and we will start using sensible names:
>>
>> /usr ->  /System
>> /etc ->  /Config
>> /var ->  /Variable
>>
>> I feel a deep respect for the people working on making mdev a
>> "replacement" of udev; it is not an easy task (even if it only works
>> for a really small subset of the use cases udev covers), and something
>> that I certainly would never do. But their hack (as beautiful as it
>> may be) will never be used by the majority of Linux users, and
>> probably not even by the majority of Gentoo users (if my
>> interpretation of the discussion on gentoo-dev is correct). And with
>> the pass of time it will be harder and harder to keep the hack working
>> with new hardware, new software, and new use cases.
>>
>> But, hey, this is FOSS; you guys go nuts hacking in whatever feature
>> (or anti-feature) you like. As in the case of this mdev hack, it may
>> even be included in the Gentoo ebuilds. Just don't expect it to be
>> supported forever, don't expect it to support general-purpose setups,
>> and certainly don't call it "a victory". It's just the same history as
>> always: the people writing the code are the ones calling the shots.
>>
>> Regards.
>
>
> I wonder how many times this has been said about other software that is now
> in wide spread use.  Keep in mind, some people think Gentoo is dying and has
> been dying for YEARS.  That's not just one package but a whole distro.

Netcraft confirms it?

>
> Will mdev replace udev, I dunno.  Thing is, you don't know that it won't
> either.  Someone could come along and help Walter and make it better than
> udev ever dreamed of being.

It's not that mdev will be better than udev, or udev better than mdev,
it's that they'll be able to service different roles very effectively.

> I just have to mention hal too.  Lots of people thought that was the new
> sliced bread and frozen pizza.  It sure did fall hard tho.

For a fair number of use cases, udev works pretty well. It's been
around for far longer, too.

> As I said about my ex once, time tells.  Sometimes, time is the only thing
> that does tell too.  Reminds me of wine although I don't drink it.

I think it's absolutely ridiculous to look at udev and mdev as winner
or loser. I'm not trying to be even-handed or fair in this; I just
think they service different needs.

Currently, the only advantage I see for udev in a server is the
ability to give network interfaces meaningful names...

-- 
:wq

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Wed, 4 Jan 2012 18:49:29 -0500
Michael Mol <mikemol@gmail.com> wrote:

> > As I said about my ex once, time tells.  Sometimes, time is the
> > only thing that does tell too.  Reminds me of wine although I don't
> > drink it.  
> 
> I think it's absolutely ridiculous to look at udev and mdev as winner
> or loser. I'm not trying to be even-handed or fair in this; I just
> think they service different needs.
> 
> Currently, the only advantage I see for udev in a server is the
> ability to give network interfaces meaningful names...


Even that isn't all that useful for me. For my servers I know exactly
which interface is which (turns out that when Dell give you 4 on-board
nics they always come up in the same order. Pretty useful.)

We do the proper thing and document every bit of hardware in a central
repo (ocsng makes this automagic) and the way it is when the box is
racked is the way it stays till it's switched off 5 years later.

Aside from disks and RAM I've only had 2 hardware failures in 4 years
(both were Adaptec RAID cards) so changing hardware is an unusual event
(and rather major at that when it does happen).

For me, udev is more of a hindrance in the data centre than a help. I
simply do not need it at all, so mdev interests me a lot.

On my notebooks and test/development VMs, that's different. Those need
udev.

On something as complex as a node manager, I do not believe there is
such a thing as one-size fits all or a universal design.

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-05 01:02, Alan McKinnon wrote:

> On my notebooks and test/development VMs, that's different. Those need
> udev.

Why does it need udev specifically? Just curious... if there's a
technical need for something else than /dev population (and possible
configuration of devices, i.e. tell the kernel what bits needs to be
switched)?

> On something as complex as a node manager, I do not believe there is
> such a thing as one-size fits all or a universal design.

Fully agree.

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Thu, 05 Jan 2012 08:30:52 +0100
pk <peterk2@coolmail.se> wrote:

> > On my notebooks and test/development VMs, that's different. Those
> > need udev.  
> 
> Why does it need udev specifically? Just curious... if there's a
> technical need for something else than /dev population (and possible
> configuration of devices, i.e. tell the kernel what bits needs to be
> switched)?

Simply because they are typical notebooks and VMs :-)

I fiddle around a lot with the hardware on those and udev deals with
that nicely considering udev is designed to deal with that nicely.

Becoming rather lazy in my old age is getting to be a factor too

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-05 08:43, Alan McKinnon wrote:

> I fiddle around a lot with the hardware on those and udev deals with
> that nicely considering udev is designed to deal with that nicely.

I confess to being quite ignorant when it comes to what magic udev does
behind the scenes but what makes it different to any other device
manager (well, I don't know any other than mdev but...)? I.e. what
technical problem(s) does udev solve that no other device manager can't?
What is the technical need for something else than a device file under
/dev that can be used to communicate with the kernel?

What I mean is: If you say "... considering udev is designed to deal
with that..." you seem to indicate that you know what it does and why it
does what it does... and henceforth the technical reason why the
rearrangements of the file system hierarchy is necessary...

> Becoming rather lazy in my old age is getting to be a factor too

Ho hum... so "you lazy old fart" is true then? ;-)

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Thu, 05 Jan 2012 09:17:23 +0100
pk <peterk2@coolmail.se> wrote:

> On 2012-01-05 08:43, Alan McKinnon wrote:
> 
> > I fiddle around a lot with the hardware on those and udev deals with
> > that nicely considering udev is designed to deal with that nicely.
> 
> I confess to being quite ignorant when it comes to what magic udev
> does behind the scenes but what makes it different to any other device
> manager (well, I don't know any other than mdev but...)? I.e. what
> technical problem(s) does udev solve that no other device manager
> can't? What is the technical need for something else than a device
> file under /dev that can be used to communicate with the kernel?
> 
> What I mean is: If you say "... considering udev is designed to deal
> with that..." you seem to indicate that you know what it does and why
> it does what it does... and henceforth the technical reason why the
> rearrangements of the file system hierarchy is necessary...

I don't claim any special deep knowledge of these things, but a
superficial glance over the packages tells you a lot. udev is designed
to deal with any realistic device needs on modern systems - it's the
kitchen sink.

mdev has a much narrower scope where things are considerably more
static.

As for re-arranging the fs layout, I think it was Canek in the last
thread that gave an excellent example of why this is needed. When
devices hotplug, or need to become active early on in the boot process,
they need to run code that can be located almost anywhere. It wouldn't
be fun trying to get a wireless keyboard going when it's start-up
script needs to get into /usr/lib/firmware and /usr isn't mounted yet.

The example was something along the lines of a machine that has no
physical keyboard or a port for one, it uses a bluetooth keyboard. But
the main file systems are encrypted using a key that's on a smartcard.
To decrypt and mount the filesystems, the drivers for keyboard,
bluetooth and smart card, plus all firmware, needs to be loaded first.
This is actually not all that far-fetched, and it's a classic bootstrap
problem first solved in the 60s. It much more complex now than it was
then but the principles behind the solution are much the same.

I do agree with collapsing the executable code in /usr into /, or
having /usr on the root partition. A separate /usr/{,s}bin is pretty
pointless and was never done for safety or maintenance reasons. It was
done way way way back when disks were small and a convenient hack was
to keep the OS on the boot device and user apps somewhere else on
bigger but slower storage (which often was remote).

If /usr is local, what really is the point of having it separate
from /? Have you ever found a Linux system in any condition that could
not start just because the stuff in /usr was available? I haven't.

Even the split between bin and sbin is arbitrary. It's only there so
that users can take sbin out of PATH and not have the screen cluttered
with endless junk when they tab-tab. It makes much more sense to me to
just have one single bin and lib location and shove everything into it.

What I do object to is any possible idea that an initramfs will be
*required* regardless. I know this isn't on the table just yet, but
it's a very small amount of creep before it is. 

> 
> > Becoming rather lazy in my old age is getting to be a factor too
> 
> Ho hum... so "you lazy old fart" is true then? ;-)

Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
definitely is. I think we decided that Neil is the lazy old fart :-)



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

Alan McKinnon wrote:
> Dunno about lazy old fart, but splog (snarky pedantic lazy old git) 
> definitely is. I think we decided that Neil is the lazy old fart :-) 

I'll take the plain "old fart" title.  lol   Drs think my body is at 
least 70 anyway.  I think my brain is old to but that's not what they 
test, YET.  o_O

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

Alan McKinnon wrote:

> Dunno about lazy old fart, but splog (snarky pedantic lazy old git) 
> definitely is. I think we decided that Neil is the lazy old
> fart :-)   

I can't be bothered to answer that one.


-- 
Neil Bothwick

Q: What's the proper plural of a 'Net-connected Windows machine?
A: A Botnet

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Thu, 5 Jan 2012 15:52:04 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> Alan McKinnon wrote:
> 
> > Dunno about lazy old fart, but splog (snarky pedantic lazy old git) 
> > definitely is. I think we decided that Neil is the lazy old
> > fart :-)   
> 
> I can't be bothered to answer that one.
> 
> 

touche :-)

-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-05 15:03, Dale wrote:

> I'll take the plain "old fart" title.  lol   Drs think my body is at
> least 70 anyway.  I think my brain is old to but that's not what they
> test, YET.  o_O

Here's the condensed version of what's happening (laughing is good for
you or so I hear):

https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6#diff-1

;-)

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

pk wrote:
> On 2012-01-05 15:03, Dale wrote:
>
>> I'll take the plain "old fart" title.  lol   Drs think my body is at
>> least 70 anyway.  I think my brain is old to but that's not what they
>> test, YET.  o_O
> Here's the condensed version of what's happening (laughing is good for
> you or so I hear):
>
> https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6#diff-1
>
> ;-)
>
> Best regards
>
> Peter K
>
>

rm -rf /usr  /lib/nvidia-current/xorg/xorg

ROFLMAO.  That one space bar hit caused a bit of trouble.  WOW.  I would have been pretty pissed.  lol

Dale

:-)  :-)

P. S.  I may be a bit.  I got to get my innards back in.  O_O



-- 
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] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-05 17:20, Dale wrote:

> rm -rf /usr  /lib/nvidia-current/xorg/xorg
> 
> ROFLMAO.  That one space bar hit caused a bit of trouble.  WOW.  I would
> have been pretty pissed.  lol

Yes, buy it's the comments (and pictures) below that made me laugh...
the link is a definite keeper... :-D

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Jan 5, 2012 11:44 PM, "pk" <peterk2@coolmail.se> wrote:
>
> On 2012-01-05 17:20, Dale wrote:
>
> > rm -rf /usr  /lib/nvidia-current/xorg/xorg
> >
> > ROFLMAO.  That one space bar hit caused a bit of trouble.  WOW.  I would
> > have been pretty pissed.  lol
>
> Yes, buy it's the comments (and pictures) below that made me laugh...
> the link is a definite keeper... :-D
>
> Best regards
>
> Peter K
>

Hehehe... geek joke at its finest :-)

Thanks for the heads up!

Rgds,

[-- Attachment #2: Type: text/html, Size: 717 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

pk wrote:
> On 2012-01-05 17:20, Dale wrote:
>
>> rm -rf /usr  /lib/nvidia-current/xorg/xorg
>>
>> ROFLMAO.  That one space bar hit caused a bit of trouble.  WOW.  I would
>> have been pretty pissed.  lol
> Yes, buy it's the comments (and pictures) below that made me laugh...
> the link is a definite keeper... :-D
>
> Best regards
>
> Peter K
>
>


Yea, they were funny.  Sort of surprising tho.  Most people were making 
a joke about it.  Mistakes happen tho.  I'm sure it wasn't intentional.

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-06 02:29, Dale wrote:

> Yea, they were funny.  Sort of surprising tho.  Most people were making
> a joke about it.  Mistakes happen tho.  I'm sure it wasn't intentional.

It's easy to make such a mistake when in a hurry, or tired or distracted
for some reason; I'm also quite sure it wasn't intentional...

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Jan 6, 2012 10:04 AM, "pk" <peterk2@coolmail.se> wrote:
>
> On 2012-01-06 02:29, Dale wrote:
>
> > Yea, they were funny.  Sort of surprising tho.  Most people were making
> > a joke about it.  Mistakes happen tho.  I'm sure it wasn't intentional.
>
> It's easy to make such a mistake when in a hurry, or tired or distracted
> for some reason; I'm also quite sure it wasn't intentional...
>

Anyways, the dev seems to take the gentle (and not so gentle) ribbings in
stride, so all is well.

(In any case, he got good promotion for his project).

What really cracked me up: someone asked, didn't the testers -- if any --
caught the error? To which another commenter replied, yes, the testers
caught the error, but they can't file a bug until they restore their /usr.

Rich XD

Rgds,

[-- Attachment #2: Type: text/html, Size: 1008 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-05 13:08, Alan McKinnon wrote:

> I don't claim any special deep knowledge of these things, but a
> superficial glance over the packages tells you a lot. udev is designed
> to deal with any realistic device needs on modern systems - it's the
> kitchen sink.
  ^^^^^^^^^^^^
Fully agree... :-/

> mdev has a much narrower scope where things are considerably more
> static.

Currently it does have a more narrow scope, yes, but that can change,
no? Although I'm not entirely convinced that a userspace dev manager is
needed (yes, devfs on Linux was an utter failure but Solaris, Mac OS X,
*BSDs use it[1] and done properly in Linux it should work just as fine)...

1: https://en.wikipedia.org/wiki/Devfs#devfs

> As for re-arranging the fs layout, I think it was Canek in the last
> thread that gave an excellent example of why this is needed. When
> devices hotplug, or need to become active early on in the boot process,
> they need to run code that can be located almost anywhere. It wouldn't
> be fun trying to get a wireless keyboard going when it's start-up
> script needs to get into /usr/lib/firmware and /usr isn't mounted yet.

Yes, I understand the need for this but... how does a wireless keyboard
work under bios/firmware (*efi)? Never tried one and never will... A
computer without ports should handle such connections in firmware
(analogy: You don't need software to drive a cable).

> I do agree with collapsing the executable code in /usr into /, or
> having /usr on the root partition. A separate /usr/{,s}bin is pretty
> pointless and was never done for safety or maintenance reasons. It was
> done way way way back when disks were small and a convenient hack was
> to keep the OS on the boot device and user apps somewhere else on
> bigger but slower storage (which often was remote).

Hm... I find it quite elegant and flexible with the separation of / and
it's various underlying directories. I guess we can agree on disagreeing
here... although, I'm a bit surprised to see you as an admin defending
the "new" way... Windows does have such a philosophy with putting
everything system related into a directory (\WINDOWS)... Ultimately one
can argue why use anything else besides Windows, it does the job
reasonably well.

> If /usr is local, what really is the point of having it separate
> from /? Have you ever found a Linux system in any condition that could
> not start just because the stuff in /usr was available? I haven't.
> 
> Even the split between bin and sbin is arbitrary. It's only there so
> that users can take sbin out of PATH and not have the screen cluttered
> with endless junk when they tab-tab. It makes much more sense to me to
> just have one single bin and lib location and shove everything into it.

I'm not an admin of a large organization so what do I know... but, I
still can appreciate the flexibility and "tidyness" it[2] gives you in a
multi-user system. I also can see this from a security point of view
("keep the cool toys from the children")... I personally like it for my
very local computer as well for the above reasons (flex./tidy).

2: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

What you are basically saying is that everything "we" have learned about
computer systems should be abolished and we adapt the monolithic, "black
box" philosophy of newish systems like Windows. That's how I interpret
what you're saying (yes, I do know hardware has changed since the 60'ies
but not that radically, IMO)... I tend to think of Unix as "Lego" where
you have lots of little bits with clean(ish) interfaces with which you
can build whatever you want. With the new philosophy it's more like
buying an Audi A2 (for those who don't know it, basically all you can do
is fill it up with petrol, oil and window fluid; anything else you need
to take it to an Audi workshop). Maybe I suck at car analogies... :-P

> Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
> definitely is. I think we decided that Neil is the lazy old fart :-)

:-D

Oh... I'm not that far behind unfortunately... so, I'm a "lazy,
pedantic, oldish, ???". ;-)

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Thu, 05 Jan 2012 16:50:45 +0100
pk <peterk2@coolmail.se> wrote:

> On 2012-01-05 13:08, Alan McKinnon wrote:

[snip]

> > mdev has a much narrower scope where things are considerably more
> > static.
> 
> Currently it does have a more narrow scope, yes, but that can change,
> no? Although I'm not entirely convinced that a userspace dev manager
> is needed (yes, devfs on Linux was an utter failure but Solaris, Mac
> OS X, *BSDs use it[1] and done properly in Linux it should work just
> as fine)...
> 
> 1: https://en.wikipedia.org/wiki/Devfs#devfs

As I understand it, devfs had unfixable race-condition problems.
Normally these things can be fixed with an architectural re-design but
Greg then showed up with udev. It's in-kernel design is quite elegant
actually. But udev then and udev now are likely very different beasts.

And that's about my limit of things I know for certain with udev

> > As for re-arranging the fs layout, I think it was Canek in the last
> > thread that gave an excellent example of why this is needed. When
> > devices hotplug, or need to become active early on in the boot
> > process, they need to run code that can be located almost anywhere.
> > It wouldn't be fun trying to get a wireless keyboard going when
> > it's start-up script needs to get into /usr/lib/firmware and /usr
> > isn't mounted yet.
> 
> Yes, I understand the need for this but... how does a wireless
> keyboard work under bios/firmware (*efi)? Never tried one and never
> will... A computer without ports should handle such connections in
> firmware (analogy: You don't need software to drive a cable).

To you and I it might seem absurd, but I think out there in the
marketplace it's quite a reasonable thing for a user to want. And if
that example never happens, there's hundreds more than can. Point
being, the code must be able to deal with such things.

> > I do agree with collapsing the executable code in /usr into /, or
> > having /usr on the root partition. A separate /usr/{,s}bin is pretty
> > pointless and was never done for safety or maintenance reasons. It
> > was done way way way back when disks were small and a convenient
> > hack was to keep the OS on the boot device and user apps somewhere
> > else on bigger but slower storage (which often was remote).
> 
> Hm... I find it quite elegant and flexible with the separation of /
> and it's various underlying directories. I guess we can agree on
> disagreeing here... although, I'm a bit surprised to see you as an
> admin defending the "new" way... Windows does have such a philosophy
> with putting everything system related into a directory (\WINDOWS)...
> Ultimately one can argue why use anything else besides Windows, it
> does the job reasonably well.

Oh, I'm not advocating doing it Windows style, I'm simply saying what's
the point of the system itself having 4 locations for binaries when I
never use that separation? I gain nothing from having a /bin and
a /usr/bin.

/opt and /usr/local/bin *are* useful so I'd keep those. Same with /var
and all the other traditional separate mount points.


> > If /usr is local, what really is the point of having it separate
> > from /? Have you ever found a Linux system in any condition that
> > could not start just because the stuff in /usr was available? I
> > haven't.
> > 
> > Even the split between bin and sbin is arbitrary. It's only there so
> > that users can take sbin out of PATH and not have the screen
> > cluttered with endless junk when they tab-tab. It makes much more
> > sense to me to just have one single bin and lib location and shove
> > everything into it.
> 
> I'm not an admin of a large organization so what do I know... but, I
> still can appreciate the flexibility and "tidyness" it[2] gives you
> in a multi-user system. I also can see this from a security point of
> view ("keep the cool toys from the children")... I personally like it
> for my very local computer as well for the above reasons (flex./tidy).
> 
> 2: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> 
> What you are basically saying is that everything "we" have learned
> about computer systems should be abolished and we adapt the
> monolithic, "black box" philosophy of newish systems like Windows.
> That's how I interpret what you're saying (yes, I do know hardware
> has changed since the 60'ies but not that radically, IMO)... I tend
> to think of Unix as "Lego" where you have lots of little bits with
> clean(ish) interfaces with which you can build whatever you want.dual
>

Good analogy. I also like building systems from individual Lego bricks.
I don't like having to build the bricks themselves first :-)

Windows goes too far to the other extreme IMO. That OS seems to have
largely abandoned control and there's not much in the way of
structure. Too little control is just as bad as too much 


[snip]



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Michael Mol]

On Thu, Jan 5, 2012 at 1:02 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Thu, 05 Jan 2012 16:50:45 +0100
> pk <peterk2@coolmail.se> wrote:
>
>> On 2012-01-05 13:08, Alan McKinnon wrote:
>> > If /usr is local, what really is the point of having it separate
>> > from /? Have you ever found a Linux system in any condition that
>> > could not start just because the stuff in /usr was available? I
>> > haven't.
>> >
>> > Even the split between bin and sbin is arbitrary. It's only there so
>> > that users can take sbin out of PATH and not have the screen
>> > cluttered with endless junk when they tab-tab. It makes much more
>> > sense to me to just have one single bin and lib location and shove
>> > everything into it.
>>
>> I'm not an admin of a large organization so what do I know... but, I
>> still can appreciate the flexibility and "tidyness" it[2] gives you
>> in a multi-user system. I also can see this from a security point of
>> view ("keep the cool toys from the children")... I personally like it
>> for my very local computer as well for the above reasons (flex./tidy).
>>
>> 2: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>>
>> What you are basically saying is that everything "we" have learned
>> about computer systems should be abolished and we adapt the
>> monolithic, "black box" philosophy of newish systems like Windows.
>> That's how I interpret what you're saying (yes, I do know hardware
>> has changed since the 60'ies but not that radically, IMO)... I tend
>> to think of Unix as "Lego" where you have lots of little bits with
>> clean(ish) interfaces with which you can build whatever you want.dual
>>
>
> Good analogy. I also like building systems from individual Lego bricks.
> I don't like having to build the bricks themselves first :-)
>
> Windows goes too far to the other extreme IMO. That OS seems to have
> largely abandoned control and there's not much in the way of
> structure. Too little control is just as bad as too much

Apparently they're going the 'app store' route in Windows 8.

-- 
:wq

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2331 bytes --]

On Thursday 05 Jan 2012 18:20:16 Michael Mol wrote:
> On Thu, Jan 5, 2012 at 1:02 PM, Alan McKinnon <alan.mckinnon@gmail.com> 
wrote:
> > On Thu, 05 Jan 2012 16:50:45 +0100
> > 
> > pk <peterk2@coolmail.se> wrote:
> >> On 2012-01-05 13:08, Alan McKinnon wrote:
> >> > If /usr is local, what really is the point of having it separate
> >> > from /? Have you ever found a Linux system in any condition that
> >> > could not start just because the stuff in /usr was available? I
> >> > haven't.
> >> > 
> >> > Even the split between bin and sbin is arbitrary. It's only there so
> >> > that users can take sbin out of PATH and not have the screen
> >> > cluttered with endless junk when they tab-tab. It makes much more
> >> > sense to me to just have one single bin and lib location and shove
> >> > everything into it.
> >> 
> >> I'm not an admin of a large organization so what do I know... but, I
> >> still can appreciate the flexibility and "tidyness" it[2] gives you
> >> in a multi-user system. I also can see this from a security point of
> >> view ("keep the cool toys from the children")... I personally like it
> >> for my very local computer as well for the above reasons (flex./tidy).
> >> 
> >> 2: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> >> 
> >> What you are basically saying is that everything "we" have learned
> >> about computer systems should be abolished and we adapt the
> >> monolithic, "black box" philosophy of newish systems like Windows.
> >> That's how I interpret what you're saying (yes, I do know hardware
> >> has changed since the 60'ies but not that radically, IMO)... I tend
> >> to think of Unix as "Lego" where you have lots of little bits with
> >> clean(ish) interfaces with which you can build whatever you want.dual
> > 
> > Good analogy. I also like building systems from individual Lego bricks.
> > I don't like having to build the bricks themselves first :-)
> > 
> > Windows goes too far to the other extreme IMO. That OS seems to have
> > largely abandoned control and there's not much in the way of
> > structure. Too little control is just as bad as too much
> 
> Apparently they're going the 'app store' route in Windows 8.

They're just playing catch up with Apple instead of trying to innovate.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

On Thu, 5 Jan 2012 13:20:16 -0500, Michael Mol wrote:

> Apparently they're going the 'app store' route in Windows 8.

WooHoo! 200 fart apps on the first day.


-- 
Neil Bothwick

... "I'm simply not a nice girl", she whispered tartly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-05 19:02, Alan McKinnon wrote:

> structure. Too little control is just as bad as too much 

Well, I am a control freak so... I started out with Redhat a long time
ago and then ended up with Linux From Scratch but it needed a bit too
much maintenance so I found Gentoo as a good compromise.

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 4495 bytes --]

On Jan 5, 2012 7:10 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Thu, 05 Jan 2012 09:17:23 +0100
> pk <peterk2@coolmail.se> wrote:
>
> > On 2012-01-05 08:43, Alan McKinnon wrote:
> >
> > > I fiddle around a lot with the hardware on those and udev deals with
> > > that nicely considering udev is designed to deal with that nicely.
> >
> > I confess to being quite ignorant when it comes to what magic udev
> > does behind the scenes but what makes it different to any other device
> > manager (well, I don't know any other than mdev but...)? I.e. what
> > technical problem(s) does udev solve that no other device manager
> > can't? What is the technical need for something else than a device
> > file under /dev that can be used to communicate with the kernel?
> >
> > What I mean is: If you say "... considering udev is designed to deal
> > with that..." you seem to indicate that you know what it does and why
> > it does what it does... and henceforth the technical reason why the
> > rearrangements of the file system hierarchy is necessary...
>
> I don't claim any special deep knowledge of these things, but a
> superficial glance over the packages tells you a lot. udev is designed
> to deal with any realistic device needs on modern systems - it's the
> kitchen sink.
>
> mdev has a much narrower scope where things are considerably more
> static.
>
> As for re-arranging the fs layout, I think it was Canek in the last
> thread that gave an excellent example of why this is needed. When
> devices hotplug, or need to become active early on in the boot process,
> they need to run code that can be located almost anywhere. It wouldn't
> be fun trying to get a wireless keyboard going when it's start-up
> script needs to get into /usr/lib/firmware and /usr isn't mounted yet.
>
> The example was something along the lines of a machine that has no
> physical keyboard or a port for one, it uses a bluetooth keyboard. But
> the main file systems are encrypted using a key that's on a smartcard.
> To decrypt and mount the filesystems, the drivers for keyboard,
> bluetooth and smart card, plus all firmware, needs to be loaded first.
> This is actually not all that far-fetched, and it's a classic bootstrap
> problem first solved in the 60s. It much more complex now than it was
> then but the principles behind the solution are much the same.
>
> I do agree with collapsing the executable code in /usr into /, or
> having /usr on the root partition. A separate /usr/{,s}bin is pretty
> pointless and was never done for safety or maintenance reasons. It was
> done way way way back when disks were small and a convenient hack was
> to keep the OS on the boot device and user apps somewhere else on
> bigger but slower storage (which often was remote).
>
> If /usr is local, what really is the point of having it separate
> from /? Have you ever found a Linux system in any condition that could
> not start just because the stuff in /usr was available? I haven't.
>
> Even the split between bin and sbin is arbitrary. It's only there so
> that users can take sbin out of PATH and not have the screen cluttered
> with endless junk when they tab-tab. It makes much more sense to me to
> just have one single bin and lib location and shove everything into it.
>
> What I do object to is any possible idea that an initramfs will be
> *required* regardless. I know this isn't on the table just yet, but
> it's a very small amount of creep before it is.
>
> >
> > > Becoming rather lazy in my old age is getting to be a factor too
> >
> > Ho hum... so "you lazy old fart" is true then? ;-)
>
> Dunno about lazy old fart, but splog (snarky pedantic lazy old git)
> definitely is. I think we decided that Neil is the lazy old fart :-)
>

After some soul-searching (yes, I still have one despite learning from
BOFH), I think I'll agree with Alan... with some caveats.

I have less resistance to requiring /usr to be part of /. The way I see it,
I can still do some bind mount black magic to provide a minimal /usr for
booting yet isolating the 'real' /usr to prevent it messing up the rootfs.

As to udev, I still think it's an overkill for a static server environment.
With virtualization, I can *guarantee* that the (virtual) hardware
environment will never change. For these environments, I much prefer mdev
to udev.

Finally, regarding initramfs, I wholly agree. Don't force me to use one. A
server is already a complex system, and adding complexity won't end up
pretty.

Rgds,

[-- Attachment #2: Type: text/html, Size: 5332 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Walter Dnes]

On Thu, Jan 05, 2012 at 08:30:52AM +0100, pk wrote
> On 2012-01-05 01:02, Alan McKinnon wrote:
> 
> > On my notebooks and test/development VMs, that's different. Those need
> > udev.
> 
> Why does it need udev specifically? Just curious... if there's a
> technical need for something else than /dev population (and possible
> configuration of devices, i.e. tell the kernel what bits needs to be
> switched)?

  I think I've found one item so far that requires udev.  My laptop's
graphics chip needs a binary blob from radeon-ucode.  That binary blob,
in turn, requires the presence of /usr/lib/libudev.so.0 which is a
symlink to /usr/lib/libudev.so.0.9.3 (which is also required).  I can

emerge udev
move or copy the 2 files over to /root
unmerge udev
move or copy the 2 files from /root to /usr/lib/

and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
64-bit gentoo.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-07 02:17, Walter Dnes wrote:

>   I think I've found one item so far that requires udev.  My laptop's
> graphics chip needs a binary blob from radeon-ucode.  That binary blob,
> in turn, requires the presence of /usr/lib/libudev.so.0 which is a
> symlink to /usr/lib/libudev.so.0.9.3 (which is also required).  I can
> 
> emerge udev
> move or copy the 2 files over to /root
> unmerge udev
> move or copy the 2 files from /root to /usr/lib/
> 
> and it still works. Note that /usr/lib/ is a symlink to /usr/lib64 on my
> 64-bit gentoo.

Hm... I also use a radeon (w/ KMS) and needs this binary blob but I
compile that into the kernel*.

*Device Drivers --->
	Generic Driver Options --->
		[*]  Include in-kernel firmware blobs in kernel binary

If you don't have it compiled in I can see why you would need udev...

Disclaimer: I assume it's not needed in my case - haven't tested though
but fail to see any technical reason for calling libudev, in this case.

Also, this work around... I'm not so sure it's a good solution to
require a pseudo need for udev which is placed on / before mounting /usr
but then again we (can) have a static /dev before {u,m}dev takes over...

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Walter Dnes]

On Sat, Jan 07, 2012 at 12:44:36PM +0100, pk wrote

> Hm... I also use a radeon (w/ KMS) and needs this binary blob but I
> compile that into the kernel*.
> 
> *Device Drivers --->
> 	Generic Driver Options --->
> 		[*]  Include in-kernel firmware blobs in kernel binary
> 
> If you don't have it compiled in I can see why you would need udev...
> 
> Disclaimer: I assume it's not needed in my case - haven't tested though
> but fail to see any technical reason for calling libudev, in this case.

  I also have that.  To test it out, I moved R600_rlc.bin from
/lib/firmware/radeon, and X still comes up. So it has been pulled into
the kernel.

  But wait, whilst screwing around, I noticed that the compile pulls in
every blob in the /lib/firmware/radeon directory...

BARTS_mc.bin    CAYMAN_pfp.bin   JUNIPER_pfp.bin  SUMO2_me.bin
BARTS_me.bin    CAYMAN_rlc.bin   JUNIPER_rlc.bin  SUMO2_pfp.bin
BARTS_pfp.bin   CEDAR_me.bin     PALM_me.bin      SUMO_me.bin
BTC_rlc.bin     CEDAR_pfp.bin    PALM_pfp.bin     SUMO_pfp.bin
CAICOS_mc.bin   CEDAR_rlc.bin    R600_rlc.bin     SUMO_rlc.bin
CAICOS_me.bin   CYPRESS_me.bin   R700_rlc.bin     TURKS_mc.bin
CAICOS_pfp.bin  CYPRESS_pfp.bin  REDWOOD_me.bin   TURKS_me.bin
CAYMAN_mc.bin   CYPRESS_rlc.bin  REDWOOD_pfp.bin  TURKS_pfp.bin
CAYMAN_me.bin   JUNIPER_me.bin   REDWOOD_rlc.bin

  I removed all but R600_rlc.bin (the one the laptop graphics chip
requires) from /lib/firmware/radeon, rebuilt the kernel, and rebooted,
and now X comes up fine without the libudev files.  This is weird.  The
only thing I can think of is...

* with only one binary blob. it "just works"

* multiple blobs should not be included in the kernel, otherwise it gets
  confused.  If multiple blobs are included, there's a fallback
  mechanism that uses udev to figure out exactly which graphics chip the
  laptop has, and which of the built-in blobs to use.

  So my laptop is now entirely udev-free.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-09 00:48, Walter Dnes wrote:

Hm... if you didn't compile it in you would have needed an initrd;
didn't think of that... :-(

> * with only one binary blob. it "just works"
>
> * multiple blobs should not be included in the kernel, otherwise it gets
>   confused.  If multiple blobs are included, there's a fallback
>   mechanism that uses udev to figure out exactly which graphics chip the
>   laptop has, and which of the built-in blobs to use.

Well, if udev has the database that connects the blob to the chip then
yes it does sounds likely but still a bit strange... I also have only
one blob (I dislike "waste" so I only put the correct blob in there). :-)

>   So my laptop is now entirely udev-free.

Congratulations! :-D

PS. I will dive into this and test mdev soon-ish (when I can find the time).

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Jan 9, 2012 3:24 PM, "pk" <peterk2@coolmail.se> wrote:
>
> On 2012-01-09 00:48, Walter Dnes wrote:
>
> Hm... if you didn't compile it in you would have needed an initrd;
> didn't think of that... :-(
>
> > * with only one binary blob. it "just works"
> >
> > * multiple blobs should not be included in the kernel, otherwise it gets
> >   confused.  If multiple blobs are included, there's a fallback
> >   mechanism that uses udev to figure out exactly which graphics chip the
> >   laptop has, and which of the built-in blobs to use.
>
> Well, if udev has the database that connects the blob to the chip then
> yes it does sounds likely but still a bit strange... I also have only
> one blob (I dislike "waste" so I only put the correct blob in there). :-)
>
> >   So my laptop is now entirely udev-free.
>
> Congratulations! :-D
>
> PS. I will dive into this and test mdev soon-ish (when I can find the
time).
>
> Best regards
>
> Peter K
>

Is it possible to load the firmware blob after booting, from the shell?

Rgds,

[-- Attachment #2: Type: text/html, Size: 1391 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-09 10:47, Pandu Poluan wrote:

> Is it possible to load the firmware blob after booting, from the shell?

I don't think so; KMS needs it to talk to the gpu so either it needs to
be in an initrd (loaded with the KMS/framebuffer module) or compiled in.
That's how I understand it anyway...

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Walter Dnes]

On Mon, Jan 09, 2012 at 04:47:22PM +0700, Pandu Poluan wrote

> Is it possible to load the firmware blob after booting, from the shell?

  I don't think so.  These are not standard kernel modules (*.o) files.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Sebastian Beßler]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On 09.01.2012 22:08, Walter Dnes wrote:
> On Mon, Jan 09, 2012 at 04:47:22PM +0700, Pandu Poluan wrote
> 
>> Is it possible to load the firmware blob after booting, from the shell?
> 
>   I don't think so.  These are not standard kernel modules (*.o) files.

You could build the radeon driver as module and load that after booting
via modprobe radeon modeset=1
The firmware then gets loaded from the module.

I do that here because building the driver inside the kernel makes
problems for me.

Greetings

Sebastian Beßler


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

On Thu, Jan 5, 2012 at 03:21, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan <pandu@poluan.info> wrote:
>>

----- >8 snip

>>
>> You were there in the thread linked by Walt, udev is just one of several
>> packages maintained by RH people that *demands* /usr to be mounted during
>> boot.
>>
>> And the RH devels insistence to deprecate /bin, /sbin, /usr/sbin...
>>
>> I'm getting depressed. One battle might be won (mdev vs udev), but there's
>> still a war against the RH braindeadness...
>
> I'm sorry to tell you this, but (as admirable as it could be), the
> mdev hack to use it instead of udev is not a "victory". We are not at
> war, in the first place; and in the second place, the mdev hack would
> be used by a handful of guys bent on refusing a change that, like it
> or not, would in the end come. Like Gentoo on FreeBSD, it would be a
> nice hack, maybe even worthy of applause, but in the end irrelevant: a
> toy. A cute, entertaining (and, in a few cases, useful) toy. But a toy
> nonetheless.
>

I may have been slightly hyperbolic in my usage of "battle" and "war",
but then again why must Gentoo bend over to the wills of RH developers
who insist on doing things their way?

And mdev might be a 'toy' to you, but embedded Linux developers will
vehemently disagree with you.

And based on the responses in this thread, server guys will also
disagree with you.

For these two groups, mdev is not a toy but a necessity.

> The heavy development will continue to happen in udev, and the devices
> that will dominate in the future (touchscreens, bluetooth input and
> audio devices, hardware that has a highly dynamic change rate) will
> only be supported by udev. The mdev hack will be useful maybe to only
> some guys, and even then udev would be able to do the same (and more).
>

The ability of mdev is more than enough for those handling the
back-end servers, thank you.

udev just adds bells and whistles *not* needed in server environs.

> The use of an initramfs (or, alternatively, having /usr in the same
> partition as /), and maybe the move of /bin to /usr/bin and /lib to
> /usr/lib will be made, and in the future most of the interesting
> software will simply assume that this is how a system works. Maybe we
> will even stop to use the ridiculous short directory names from the
> stone age, and we will start using sensible names:
>
> /usr -> /System
> /etc -> /Config
> /var -> /Variable
>

I can agree with sensible names. Unfortunately, forcing sensible names
upon servers *already* in the field is a sure fire recipe to disaster.

Besides, the FHS itself explains the reasoning behind each directory.

As to the forced use of initramfs, again it runs counter to the wishes
of embedded Linux people (for whom storage is at a premium) and the
wishes of server people (whom would prefer as few 'breaking points' as
possible).

(As a side note, initramfs introduces not one, but *MANY* additional
breaking points: the tool used to generate the initramfs might be
buggy and/or feature-incomplete, the initramfs itself might encounter
an unrecoverable error, the pivot_root or chroot might snag upon some
not-so-edge cases, etc.)

> I feel a deep respect for the people working on making mdev a
> "replacement" of udev; it is not an easy task (even if it only works
> for a really small subset of the use cases udev covers), and something
> that I certainly would never do. But their hack (as beautiful as it
> may be) will never be used by the majority of Linux users, and
> probably not even by the majority of Gentoo users (if my
> interpretation of the discussion on gentoo-dev is correct). And with
> the pass of time it will be harder and harder to keep the hack working
> with new hardware, new software, and new use cases.
>
> But, hey, this is FOSS; you guys go nuts hacking in whatever feature
> (or anti-feature) you like. As in the case of this mdev hack, it may
> even be included in the Gentoo ebuilds. Just don't expect it to be
> supported forever, don't expect it to support general-purpose setups,
> and certainly don't call it "a victory". It's just the same history as
> always: the people writing the code are the ones calling the shots.
>

As long as there are embedded Linux, mdev *will* be maintained and
supported in perpetuum.

Besides, the so-called mdev "hack" is really just a small script which
gets executed before "init" runs. The other convoluted steps waltdnes
had provided is just necessary to fix the virtual/dev-manager ebuild
to allow using mdev instead of udev (and, with the acceptance of his
bug report, we will soon see in the main portage tree). The actual
steps to replace udev with mdev are very simple.

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

The 05/01/12, Pandu Poluan wrote:

> And mdev might be a 'toy' to you, but embedded Linux developers will
> vehemently disagree with you.
> 
> And based on the responses in this thread, server guys will also
> disagree with you.

On the embedded side, we need udev much more than you think to support
bluetooth, tablet and so. Android uses udev. This is even more true when
we know that users will expect to have any plugged-in devices at
whatever boot time or runing system be working out of the box. BTW, this
is not a major problem since embedded devices already often use initramfs.

On servers, I wouldn't be surprised that hypervisor tools will expect
/dev/cdrom instead of /dev/sr0.
AFAIK, mdev doesn't provide persistent device names and changing a
ethernet card might result in a highly broken system where udev will let
all interfaces working but the changed one.  Worse, I think mdev might
change of device names upon reboot so that all ethernet devices can be
mixed up in ways like eth0 -> eth1, eth1 -> eth3 and eth2 -> eth0.

These are only few examples and this is whole mdev hack (requirements
and consequences) that makes "mdev alternative" look like a toy.

People thinking that mdev could replace udev even on embedded devices
and servers are wrong for both current or longer term.
You might like it or not but udev is a core system tool, nowadays.

As admin, I will expect to have a initramfs and udev on linux systems
whatever they are desktop, embedded or servers. Actually, I already rely
on initramfs for all of these kind of systems for years with success.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Thu, 5 Jan 2012 11:01:49 +0100, Nicolas Sebrecht wrote:

> You might like it or not but udev is a core system tool, nowadays.

Yes, today. It wasn't yesterday and it may not be tomorrow. I like udev,
but I do not like the direction it is taking. I am not alone in this and
there may be a critical mass needed to create an alternative, whether
that be an evolution of mdev or something completely new.

You cannot assume that you can make whatever changes you want and all
users will follow, that's why there are so many new Xubuntu and Mint
users.

You are clearly happy with udev and already want/need an initramfs. Don't
fall into the same trap as the udev developers and think that what you
want it was everyone else wants.


-- 
Neil Bothwick

Power corrupts. Absolute power is kind of neat.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Michael Mol]

On Thu, Jan 5, 2012 at 5:01 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> The 05/01/12, Pandu Poluan wrote:
>
>> And mdev might be a 'toy' to you, but embedded Linux developers will
>> vehemently disagree with you.
>>
>> And based on the responses in this thread, server guys will also
>> disagree with you.
>
> On the embedded side, we need udev much more than you think to support
> bluetooth, tablet and so. Android uses udev. This is even more true when
> we know that users will expect to have any plugged-in devices at
> whatever boot time or runing system be working out of the box. BTW, this
> is not a major problem since embedded devices already often use initramfs.
>
> On servers, I wouldn't be surprised that hypervisor tools will expect
> /dev/cdrom instead of /dev/sr0.
> AFAIK, mdev doesn't provide persistent device names and changing a
> ethernet card might result in a highly broken system where udev will let
> all interfaces working but the changed one.  Worse, I think mdev might
> change of device names upon reboot so that all ethernet devices can be
> mixed up in ways like eth0 -> eth1, eth1 -> eth3 and eth2 -> eth0.

FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
alone udev.

Also, ethN numberings are generally stable until and unless you do
some strange BIOS tweaking or hardware changes, and should be able to
be stabilized in the event the instability comes from some racy module
loading mechanism.

udev's attempts at stabilizing network interfaces have made things
worse more often than I've heard of it making them better. Hit any
search engine for "eth0 missing 70-persistent-net.rules".

(Apologies for anyone who sees this message in such a result; just
delete /etc/udev/rules.d/70-persistent-net.rules, and you should get
eth0 back.)
-- 
:wq

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

On Thu, Jan 05, 2012 at 02:20:21PM -0500, Michael Mol wrote:

> FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
> alone udev.

We are not looking for device paths that existed berfore udev. Actually,
most of them exist since much more time than udev. It's not relevant at
all.

> Also, ethN numberings are generally stable until and unless you do
> some strange BIOS tweaking or hardware changes, and should be able to
> be stabilized in the event the instability comes from some racy module
> loading mechanism.

This is not true. I've had computers in hands where network cards could
change of names without any BIOS tunning. BIOS is a executed program and
the way each is implemented can guarantee *or not* to have the
conditions for persistent NIC names on Linux.

> udev's attempts at stabilizing network interfaces have made things
> worse more often than I've heard of it making them better. Hit any
> search engine for "eth0 missing 70-persistent-net.rules".

It's fully expected and required. Persistent naming can work if you have
a configuration for that somewhere. I see nothing worse here. But I see
an improvement to let me tune the NIC names if I need to. I have routers
with *lot of* NIC cards where this feature is very usefull (expressive
names are much better than ethX).

> (Apologies for anyone who sees this message in such a result; just
> delete /etc/udev/rules.d/70-persistent-net.rules, and you should get
> eth0 back.)

<still quoting to help beginners>

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Michael Mol]

On Thu, Jan 5, 2012 at 5:08 PM, Nicolas Sebrecht
<nicolas.s-dev@laposte.net> wrote:
> On Thu, Jan 05, 2012 at 02:20:21PM -0500, Michael Mol wrote:
>
>> FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
>> alone udev.
>
> We are not looking for device paths that existed berfore udev. Actually,
> most of them exist since much more time than udev. It's not relevant at
> all.

You missed my point. My point was that udev wasn't needed to resolve
the use case you described, that stable solutions to such cases
preceded udev, and so udev wasn't a necessary tool to solve them.

>
>> Also, ethN numberings are generally stable until and unless you do
>> some strange BIOS tweaking or hardware changes, and should be able to
>> be stabilized in the event the instability comes from some racy module
>> loading mechanism.
>
> This is not true. I've had computers in hands where network cards could
> change of names without any BIOS tunning.

Did this happen after a kernel update or a change to your kernel
configuration? A software update? A change in the set of enabled
modules, or which were built-in vs built as modules?

In any production server environment, I would assume you're already
watching the thing like a hawk and verifying that the thing comes up
properly after a reboot. Reboots should be very, very rare things. I
try to do things more or less correctly on a high-profile machine, and
I'm still giddy when the once-in-a-blue-moon reboot doesn't break
anything.

> BIOS is a executed program and
> the way each is implemented can guarantee *or not* to have the
> conditions for persistent NIC names on Linux.

What you're saying is that NIC stability is dependent on how the OEM
built the BIOS and software. I'll posit there may be strange NICs out
there which can't be initialized within a deterministic time frame
without some external factor such as a link handshake. If this were a
common behavior for a piece of hardware though, I'd consider it
indicative of shoddy quality, and would want to replace it.
Regardless, it's resolvable in software without using a tool that
imposes significant restrictions on system structure.

>
>> udev's attempts at stabilizing network interfaces have made things
>> worse more often than I've heard of it making them better. Hit any
>> search engine for "eth0 missing 70-persistent-net.rules".
>
> It's fully expected and required. Persistent naming can work if you have
> a configuration for that somewhere. I see nothing worse here.

One week, I helped no fewer than five people who ran afoul of the
70-persistent-net.rules file, and didn't know why their eth0
disappeared. These weren't newbie Linux users, either. Some knew their
way around GNOME better than I still do, and they mostly knew their
way around the shell. Some were networking professionals pulling more
than I do.

I'd wager the vast majority of systems out there have devices named as
'ethN' for wired connections, and 'wlanN', 'athN' or whatever for
wireless connections. And that the vast majority of those systems have
one or fewer wired connection ports. And that the further vast
majority of those don't have customized 70-persistent-net.rules files
as you and I have. If that's true, then the persistent-net rules
behavior currently harms more users than it benefits.

> But I see
> an improvement to let me tune the NIC names if I need to. I have routers
> with *lot of* NIC cards where this feature is very usefull (expressive
> names are much better than ethX).

I, too, noted this as a potential advantage of udev. On my router, I
have five interfaces. 'wan', 'he-tunnel', lan, wifi, lo and 'tun0'.
tun0 is only so-named because it's an OpenVPN thing I haven't bothered
to change. I've tried to advocate use this feature of udev.

But I administer my router the way I like to. Most people I've pointed
toward this capability just go "Meh. I have a list of interfaces and
what they're for." even when they already have udev.

-- 
:wq

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Thu, 5 Jan 2012 16:38:20 -0500
Michael Mol <mikemol@gmail.com> wrote:

> > But I see
> > an improvement to let me tune the NIC names if I need to. I have
> > routers with *lot of* NIC cards where this feature is very usefull
> > (expressive names are much better than ethX).  
> 
> I, too, noted this as a potential advantage of udev. On my router, I
> have five interfaces. 'wan', 'he-tunnel', lan, wifi, lo and 'tun0'.
> tun0 is only so-named because it's an OpenVPN thing I
> haven't bothered to change. I've tried to advocate use this feature
> of udev.
> 
> But I administer my router the way I like to. Most people I've pointed
> toward this capability just go "Meh. I have a list of interfaces and
> what they're for." even when they already have udev.

I see that as a liability not a feature.

Our routers have very clear naming conventions for interfaces and they
are exactly how Cisco enumerates them and no other way. It's a firing
offense to dick with them and dream up useless "descriptive names".

Mind you, these for the most part are big iron with several 1000
interfaces each and 100+ support personnel working on them. But even
the on-site routers and firewalls at customer premises have the same
rule.

I assume we are talking about kit that routes properly (whether a
Unix or something else is not relevant) and not some joke system.


As for NICs that do not come up at boot time in a consistent
order, if any piece of hardware in our DC did that it would be sent
right back to the vendor labeled as a piece of shit with a demand for a
refund. FFS, if my boss shells out 3 months wages for some iron and it
can't even get something that basic correct, I start to wonder what
else might be dodgy.

There is ZERO excuse for a system that cannot deterministically
enumerate it's fixed devices at boot time. 


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

Alan McKinnon wrote:
> I see that as a liability not a feature. Our routers have very clear 
> naming conventions for interfaces and they are exactly how Cisco 
> enumerates them and no other way. It's a firing offense to dick with 
> them and dream up useless "descriptive names". Mind you, these for the 
> most part are big iron with several 1000 interfaces each and 100+ 
> support personnel working on them. But even the on-site routers and 
> firewalls at customer premises have the same rule. I assume we are 
> talking about kit that routes properly (whether a Unix or something 
> else is not relevant) and not some joke system. As for NICs that do 
> not come up at boot time in a consistent order, if any piece of 
> hardware in our DC did that it would be sent right back to the vendor 
> labeled as a piece of shit with a demand for a refund. FFS, if my boss 
> shells out 3 months wages for some iron and it can't even get 
> something that basic correct, I start to wonder what else might be 
> dodgy. There is ZERO excuse for a system that cannot deterministically 
> enumerate it's fixed devices at boot time. 

I have a couple desktop rigs.  I had a card that would sometimes not do 
right and change the order of my cards numbering.  Since it was earlier 
than the card that hooked to my modem, it would mess up my connection to 
the internet.  The card was eth0 and I had internet coming through on 
eth2.  That rig now has two nics.  The defective nic was removed.  It 
has a new address called /dev/dump.

It may be a desktop rig but I like them being recognized the same each 
time I reboot.  Although, I forgot about being able to give them names. 
< scratches chin >  Nah, I'll leave well enough alone.  It's working and 
we don't mess with what is working, except for Fedora devs.  lol

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Jan 6, 2012 8:50 AM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Alan McKinnon wrote:
>>
>> I see that as a liability not a feature. Our routers have very clear
naming conventions for interfaces and they are exactly how Cisco enumerates
them and no other way. It's a firing offense to dick with them and dream up
useless "descriptive names". Mind you, these for the most part are big iron
with several 1000 interfaces each and 100+ support personnel working on
them. But even the on-site routers and firewalls at customer premises have
the same rule. I assume we are talking about kit that routes properly
(whether a Unix or something else is not relevant) and not some joke
system. As for NICs that do not come up at boot time in a consistent order,
if any piece of hardware in our DC did that it would be sent right back to
the vendor labeled as a piece of shit with a demand for a refund. FFS, if
my boss shells out 3 months wages for some iron and it can't even get
something that basic correct, I start to wonder what else might be dodgy.
There is ZERO excuse for a system that cannot deterministically enumerate
it's fixed devices at boot time.
>
>
> I have a couple desktop rigs.  I had a card that would sometimes not do
right and change the order of my cards numbering.  Since it was earlier
than the card that hooked to my modem, it would mess up my connection to
the internet.  The card was eth0 and I had internet coming through on eth2.
 That rig now has two nics.  The defective nic was removed.  It has a new
address called /dev/dump.
>
> It may be a desktop rig but I like them being recognized the same each
time I reboot.  Although, I forgot about being able to give them names. <
scratches chin >  Nah, I'll leave well enough alone.  It's working and we
don't mess with what is working, except for Fedora devs.  lol
>

mdev is capable of renaming devices, you know ;-)

https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/mdev.txt

Rgds,

[-- Attachment #2: Type: text/html, Size: 2320 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]

Pandu Poluan wrote:
>
>
> On Jan 6, 2012 8:50 AM, "Dale" <rdalek1967@gmail.com 
> <mailto:rdalek1967@gmail.com>> wrote:
> >
> > Alan McKinnon wrote:
> >>
> >> I see that as a liability not a feature. Our routers have very 
> clear naming conventions for interfaces and they are exactly how Cisco 
> enumerates them and no other way. It's a firing offense to dick with 
> them and dream up useless "descriptive names". Mind you, these for the 
> most part are big iron with several 1000 interfaces each and 100+ 
> support personnel working on them. But even the on-site routers and 
> firewalls at customer premises have the same rule. I assume we are 
> talking about kit that routes properly (whether a Unix or something 
> else is not relevant) and not some joke system. As for NICs that do 
> not come up at boot time in a consistent order, if any piece of 
> hardware in our DC did that it would be sent right back to the vendor 
> labeled as a piece of shit with a demand for a refund. FFS, if my boss 
> shells out 3 months wages for some iron and it can't even get 
> something that basic correct, I start to wonder what else might be 
> dodgy. There is ZERO excuse for a system that cannot deterministically 
> enumerate it's fixed devices at boot time.
> >
> >
> > I have a couple desktop rigs.  I had a card that would sometimes not 
> do right and change the order of my cards numbering.  Since it was 
> earlier than the card that hooked to my modem, it would mess up my 
> connection to the internet.  The card was eth0 and I had internet 
> coming through on eth2.  That rig now has two nics.  The defective nic 
> was removed.  It has a new address called /dev/dump.
> >
> > It may be a desktop rig but I like them being recognized the same 
> each time I reboot.  Although, I forgot about being able to give them 
> names. < scratches chin >  Nah, I'll leave well enough alone.  It's 
> working and we don't mess with what is working, except for Fedora 
> devs.  lol
> >
>
> mdev is capable of renaming devices, you know ;-)
>
> https://svn.mcs.anl.gov/repos/ZeptoOS/trunk/BGP/packages/busybox/src/docs/mdev.txt
>
> Rgds,
>

udev does too.  I'm just used to et0, eth1 etc.  If I renamed them, I'd 
forget the names anyway.  Then I would have to /etc/init.d/<tab tab> 
then slap forehead.  lol

Right now, I only use one nic on each rig.  I got a Linksys router now.  
I used to use my main rig as a router so it had three nics not counting 
the built in which I didn't use and was disabled in the BIOS.

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"


[-- Attachment #2: Type: text/html, Size: 3773 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Thu, 5 Jan 2012 16:07:04 +0700
Pandu Poluan <pandu@poluan.info> wrote:

> (As a side note, initramfs introduces not one, but *MANY* additional
> breaking points: the tool used to generate the initramfs might be
> buggy and/or feature-incomplete, the initramfs itself might encounter
> an unrecoverable error, the pivot_root or chroot might snag upon some
> not-so-edge cases, etc.)

I completely agree. But if we take one more step backwards for a wider
view we see something even more bizarre:


I switch on a modern computer and it:

- loads a feature rich OS (UEFI) from a fixed point in firmware which
  then

- loads a feature rich OS (grub2) from a fixed point on a storage
  device which then

- loads a feature rich OS (initrd) from a variable location on a
  storage device which then

- loads the real OS (the thing I actually wanted).

So, let's see now. I need 4 OSes to get one. Wow. If a design engineer
pulled that stunt in almost any other field of technology, he'd be
laughed out of Dodge in a heartbeat.

Methinks someone (many someones) completely lost the plot a long time
ago.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[pk]

On 2012-01-05 12:46, Alan McKinnon wrote:

> I switch on a modern computer and it:
> 
> - loads a feature rich OS (UEFI) from a fixed point in firmware which
>   then
> 
> - loads a feature rich OS (grub2) from a fixed point on a storage
>   device which then

This is a precise argument why coreboot (and filo for grub(n)) is
needed... Unfortunately it's not widely available for consumers... :-(
I do have a couple of motherboards with switchable flash roms that I
intend to get coreboot on, "when I can find the time"... sigh...

> - loads a feature rich OS (initrd) from a variable location on a
>   storage device which then

Haven't used this since I got rid of Redhat 5.x (or maybe it was
6.x?)... and never will again even if that means going the non-linux route.

> - loads the real OS (the thing I actually wanted).
> 
> So, let's see now. I need 4 OSes to get one. Wow. If a design engineer
> pulled that stunt in almost any other field of technology, he'd be
> laughed out of Dodge in a heartbeat.

Couldn't agree more!

> Methinks someone (many someones) completely lost the plot a long time
> ago.

Yes, and we're continuing along that path, it seems.

Best regards

Peter K

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Alan McKinnon]

On Tue, 3 Jan 2012 13:32:09 +0100
Nicolas Sebrecht <nsebrecht@piing.fr> wrote:

> The 03/01/12, Pandu Poluan wrote:
> 
> > (Come to think of it, has *any* distro ever attempted this...
> > 'unconventional of going udev-free?)
> 
> mdev is not an udev replacement. It's a very minimalist udev designed
> for embedded systems and initramfs. These days, a full-featured system
> require a dynamic /dev and AFAIK the only existing and up-to-date tool
> for this job is udev.
> 
> I don't think any other distro attempted to get free of udev as it
> means coming back to 10 years ago, at least.
> 

If you go back through the list archives you will find the enormous
thread that caused Walter to start down this road in the first place.
His efforts are an attempt to deal with the gigantic bloat-fest that
the udev devs seem to revel in.

Walter is doing fine work, he should be supported in this.



-- 
Alan McKinnnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

The 03/01/12, Alan McKinnon wrote:

> If you go back through the list archives you will find the enormous
> thread that caused Walter to start down this road in the first place.
> His efforts are an attempt to deal with the gigantic bloat-fest that
> the udev devs seem to revel in.

If you go back through the list archives you will find that I'm envolved
in this thread. ,-p

> Walter is doing fine work, he should be supported in this.

It's free software so everybody can feel free to support him, of course.
I think it's time consummed in the wrong road. I'm a bit curious how
long this alternative can survive. :-)

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Volker Armin Hemmann]

Am Dienstag, 3. Januar 2012, 14:36:08 schrieb Nicolas Sebrecht:
> The 03/01/12, Alan McKinnon wrote:
> > If you go back through the list archives you will find the enormous
> > thread that caused Walter to start down this road in the first place.
> > His efforts are an attempt to deal with the gigantic bloat-fest that
> > the udev devs seem to revel in.
> 
> If you go back through the list archives you will find that I'm envolved
> in this thread. ,-p
> 
> > Walter is doing fine work, he should be supported in this.
> 
> It's free software so everybody can feel free to support him, of course.
> I think it's time consummed in the wrong road. I'm a bit curious how
> long this alternative can survive. :-)

since Walter does it to ease an itch he is feeling and since Walter is doing 
this for fun 'time consumed in the wrong road' is not an argument.

Other people love to build miniature F1 cars and put them behind glass. Waste 
of time? From my POV sure. From theirs? Hell no!

-- 
#163933

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

The 03/01/12, Volker Armin Hemmann wrote:
> Am Dienstag, 3. Januar 2012, 14:36:08 schrieb Nicolas Sebrecht:

> > It's free software so everybody can feel free to support him, of course.
> > I think it's time consummed in the wrong road. I'm a bit curious how
> > long this alternative can survive. :-)
> 
> since Walter does it to ease an itch he is feeling and since Walter is doing 
> this for fun 'time consumed in the wrong road' is not an argument.

Of course, it's not an argument. It's my feeling. I'm not against people
hacking on crazy ideas. I do it myself when I think it worth.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Dale]

Nicolas Sebrecht wrote:
> The 03/01/12, Alan McKinnon wrote:
>
>> If you go back through the list archives you will find the enormous
>> thread that caused Walter to start down this road in the first place.
>> His efforts are an attempt to deal with the gigantic bloat-fest that
>> the udev devs seem to revel in.
> If you go back through the list archives you will find that I'm envolved
> in this thread. ,-p
>
>> Walter is doing fine work, he should be supported in this.
> It's free software so everybody can feel free to support him, of course.
> I think it's time consummed in the wrong road. I'm a bit curious how
> long this alternative can survive. :-)
>

Personally, I hope to turns out to be a replacement for udev, if for no 
other reason than to be a poke in the eye of the fedora dev that started 
this crap to begin with.

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] Re: Beta test Gentoo with mdev instead of udev; version 3

[Walter Dnes]

On Tue, Jan 03, 2012 at 05:22:09PM +0700, Pandu Poluan wrote

> (Come to think of it, has *any* distro ever attempted this...
> 'unconventional of going udev-free?)

  Alpine linux has done it http://alpinelinux.org/  Unfortunately,
they're so minimalistic and server-oriented that they use uclibc instead
of glibc.  So Alpine is not viable as a desktop distro.  Think of it as

Gentoo with mdev instead of udev == Alpine with glibc instead of uclibc

  By the way, there's a thread on the Gentoo developer list discussing
the situation, and the proposed move of a bunch of stuff to /usr.  See
http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=245148;page=1;mh=-1;list=gentoo;sb=post_latest_reply;so=ASC

  I piped up with my proposal.  We'll see what happens.

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Nicolas Sebrecht]

The 03/01/12, Walter Dnes wrote:
> On Tue, Jan 03, 2012 at 05:22:09PM +0700, Pandu Poluan wrote
> 
> > (Come to think of it, has *any* distro ever attempted this...
> > 'unconventional of going udev-free?)
> 
>   Alpine linux has done it http://alpinelinux.org/  Unfortunately,
> they're so minimalistic and server-oriented that they use uclibc instead
> of glibc.

Hugh?

http://alpinelinux.org/apk/main/x86/udev

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1864 bytes --]

On Tuesday 03 Jan 2012 15:22:29 Walter Dnes wrote:
> On Tue, Jan 03, 2012 at 05:22:09PM +0700, Pandu Poluan wrote
> 
> > (Come to think of it, has *any* distro ever attempted this...
> > 'unconventional of going udev-free?)
> 
>   Alpine linux has done it http://alpinelinux.org/  Unfortunately,
> they're so minimalistic and server-oriented that they use uclibc instead
> of glibc.  So Alpine is not viable as a desktop distro.  Think of it as
> 
> Gentoo with mdev instead of udev == Alpine with glibc instead of uclibc
> 
>   By the way, there's a thread on the Gentoo developer list discussing
> the situation, and the proposed move of a bunch of stuff to /usr.  See
> http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=245148;
> page=1;mh=-1;list=gentoo;sb=post_latest_reply;so=ASC
> 
>   I piped up with my proposal.  We'll see what happens.

I'd like to thank Walter for doing something about this and Pandu for testing 
it, rather than just wingeing (like I did).  :p

I don't hold any hope that mdev will replace udev, but that this effort may go 
someway to influence the development philosophy that has been entertained to 
date with udev.  A philosophy that removes choice and flexibility.  This is 
felt more by Gentoo users, because Gentoo as we know is not a binary distro 
and the needs of its users are more nuanced and eclectic.

As I recall from this mammoth thread mdev is one option, a staged mounting of 
devices/running of scripts by udev is another.  Anything that will make udev 
devs to stop for a minute and think again the impact of their choices on the 
overall Linux community will be of benefit.  If Walter's good effort bring this 
about I would be more than happy to support him, although with a laptop using 
mdev may not be my immediate preferred solution.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 4

[Walter Dnes]

  This revision removes a couple of steps in the process, so there's
less stuff involved.  If only software developers worked that way <G>.

* Busybox stable is now past the buggy version that didn't work with
mdev.  There is no need to keyword version 1.19.2

* The virtual/dev-manager-0.ebuild has been modified as per my feature
request to support an mdev-based system.  There is no longer any need
for a customized/hacked ebuild in an overlay
 
  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) In the bootloader append line, include "init=/sbin/linuxrc" where
   the file /sbin/linuxrc consists of *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.  If you're using lilo remember
   to re-run lilo to implement the changes.

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) ***THIS STEP IS OPTIONAL***  This is only to alay any suspicion that
   udev is still in use.

* 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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 4

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]

On Feb 18, 2012 6:46 AM, "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
>  This revision removes a couple of steps in the process, so there's
> less stuff involved.  If only software developers worked that way <G>.
>
> * Busybox stable is now past the buggy version that didn't work with
> mdev.  There is no need to keyword version 1.19.2
>
> * The virtual/dev-manager-0.ebuild has been modified as per my feature
> request to support an mdev-based system.  There is no longer any need
> for a customized/hacked ebuild in an overlay
>
>  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) In the bootloader append line, include "init=/sbin/linuxrc" where
>   the file /sbin/linuxrc consists of *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.  If you're using lilo remember
>   to re-run lilo to implement the changes.
>
> 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) ***THIS STEP IS OPTIONAL***  This is only to alay any suspicion that
>   udev is still in use.
>
> * 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
>

Thanks for the update!

I've been mdev-ing my servers, and no problems whatsoever until now (touch
wood!).

For those still on the sidelines re: mdev-for-udev, be aware that progress
is happening rapidly with regards to what udev feature is 'vital' for
modern systems.

Heck, mdev is already perfect for my needs: it can rename devices, fire up
a script on hotplug/hotunplug events, load a firmware if told so by the
kernel...

I suggest interested people should at least lurk in the busybox mailing
list. The mdev-for-udev discussion us quite fresh, patches (not bloats)
have been submitted... and we have our very own Walt Dnes in that list,
proudly waving the Gentoo banner ;-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 4327 bytes --]

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 4

[Pandu Poluan]

On Sat, Feb 18, 2012 at 06:40, Walter Dnes <waltdnes@waltdnes.org> wrote:
>

---- >8 snip

>
> 3) In the bootloader append line, include "init=/sbin/linuxrc" where
>   the file /sbin/linuxrc consists of *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.  If you're using lilo remember
>   to re-run lilo to implement the changes.
>

I suggest splitting this step into two:

3a) Create /sbin/linuxrc containing at least ... chmod ...

3b) Append "init=/sbin/linuxrc" to bootloader line

Slightly less confusing :-)

Rgds,
-- 
FdS Pandu E Poluan
~ IT Optimizer ~

 • LOPSA Member #15248
 • Blog : http://pepoluan.tumblr.com
 • Linked-In : http://id.linkedin.com/in/pepoluan

Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 4

[Walter Dnes]

On Mon, Feb 27, 2012 at 04:49:40PM +0700, Pandu Poluan wrote

> I suggest splitting this step into two:
> 
> 3a) Create /sbin/linuxrc containing at least ... chmod ...
> 
> 3b) Append "init=/sbin/linuxrc" to bootloader line
> 
> Slightly less confusing :-)

  OK.  I'll modify it as suggested.  There is talk on the gentoo-dev
list that mod-utils will be replaced by virtual/mod-utils which will
default to kmod (required to build udev-181).  Note that mod-utils and
kmod are mutually exclusive.  That should be taken care of in the
ebuilds, but I'll monitor the situation.  I may have to modify the setup
instructions for conversion to mdev... i.e. an additional step, removing
kmod and installing mod-utils.

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Walter Dnes]

  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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Daddy]

[-- Attachment #1: Type: text/plain, Size: 3119 bytes --]

On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@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 <waltdnes@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

[-- Attachment #2: Type: text/html, Size: 5606 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Alan McKinnon]

On Sun, 11 Mar 2012 07:27:05 -0400 (EDT)
Daddy <daddy@happypenguincomputers.com> wrote:

> On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@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 <waltdnes@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Canek Peláez Valdés]

On Sun, Mar 11, 2012 at 8:17 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Sun, 11 Mar 2012 07:27:05 -0400 (EDT)
> Daddy <daddy@happypenguincomputers.com> wrote:
>
>> On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@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 <waltdnes@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

[Daddy]

[-- Attachment #1: Type: text/plain, Size: 8686 bytes --]

On March 11, 2012 at 10:17 AM Alan McKinnon <alan.mckinnon@gmail.com>
wrote:

> On Sun, 11 Mar 2012 07:27:05 -0400 (EDT)
> Daddy <daddy@happypenguincomputers.com> wrote:
>
> > On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@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 <waltdnes@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.mckinnon@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 1984, but dropped out of society in totality from
1986 until 1996. In '97 an old PC was given me, then in '98 we bought a
bare bones desktop box online and applied some nasty Mickey$oft OS to it.
Subsequent hardware failures led me down the path I'm on today.

In 1999 a Linux geek where I worked introduced me to RedHat, which couldn't
be successfully updated on my dialup connection. To me at that time, it
looked like some hobby kit you'd get from Radio Shack.

In 2003, while living in China, one of the principles of the privacy
service we used out of Virginia convinced me my computer was fast enough,
and rather than making a RAID0 with the second drive, to "try Linux". It
was RedHat 9.0, and after one month the distro itself sickened me.

However, in that length of time I'd found "cdrecord" and various other apps
and scripts via CLI ... and seen the ability of Linux to multitask ... and
I was hooked. The next few months were spent on Debian, with a kind
gentleman from Belgium offering to mentor me. But all he offered, it turned
out, were his scripts to do things. One day he just disappeared off the
face of the earth.

By that time I'd gotten addicted to rebuilding my kernel, especially
getting it down to < 1.0MB. And since this guy's "script" was the only way
I'd done it, me and Google struck out for the bright, new Linux horizon.
Someone had pointed me to "The Cathedral and The Bazaar", also, and my mind
was made up. The business model and practices of Mickey$oft and that
fruitloop company had opened my eyes to a world I wished I'd never seen, so
I was looking for a way out. (They'd stolen, and killed by lawsuit, two
particular projects of interest to me.)

After a month of reading (primarily some Google groups and
LinuxQuestions.org), it seemed that my desires would best be met by (a)
LFS, (b) Gentoo, or (c) Slackware. Not wanting to spend so much time
compiling from source, not knowing the benefit, and having Gentoo buddies
who regularly broke their system and spent more time compiling than I spent
awake -- Slackware became my Linux distro. From Nov 2003 until the end of
2010, I was a Slacker.

Eventually the Slackware community no longer appealed to me (nicest thing I
can say). Most of my time working on projects was spent with the #2 in
Slackware via email and IM anyway.

In January 2011 we moved from China back to America. The other big change
was my migration to Gentoo.

Today we have 1 workstation, 1 server, one PC, and 2 laptops running Gentoo
(all but one laptop have no other OS). No devices plugged into our LAN are
automounted.

My server is headless and X-less; all the other comps run Fluxbox. IMO
there is no need for a desktop environment, but then, we use our computers
for work. When we want to play we leave them alone.

We opened Happy Penguin Computers 5 months after returning to America, and
are still getting established. That's my introduction to this list.

</story>

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.

Kindest regards,
Bruce Hill

[-- Attachment #2: Type: text/html, Size: 13776 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[David Abbott]

On Sun, Mar 11, 2012 at 3:37 PM, Daddy <daddy@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

[Alan McKinnon]

On Sun, 11 Mar 2012 16:10:14 -0400
David Abbott <david@pythontoo.com> wrote:

> On Sun, Mar 11, 2012 at 3:37 PM, Daddy
> <daddy@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Dale]

Alan McKinnon wrote:
> On Sun, 11 Mar 2012 16:10:14 -0400
> David Abbott <david@pythontoo.com> wrote:
> 
>> On Sun, Mar 11, 2012 at 3:37 PM, Daddy
>> <daddy@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

[Daddy]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]




On March 11, 2012 at 5:20 PM Dale <rdalek1967@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 <:-)}

[-- Attachment #2: Type: text/html, Size: 1317 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Dale]

Daddy wrote:
>  
> 
> 
> On March 11, 2012 at 5:20 PM Dale <rdalek1967@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"

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Peter Humphrey]

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

[Alan McKinnon]

On Tue, 13 Mar 2012 02:41:15 +0000
Peter Humphrey <peter@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Tue, 13 Mar 2012 02:41:15 +0000, 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Peter Humphrey]

On Tuesday 13 March 2012 11:01:29 Neil Bothwick wrote:
> On Tue, 13 Mar 2012 02:41:15 +0000, 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

[Daddy]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On March 11, 2012 at 4:10 PM David Abbott <david@pythontoo.com> wrote:

> On Sun, Mar 11, 2012 at 3:37 PM, Daddy <daddy@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. <:-)}

[-- Attachment #2: Type: text/html, Size: 1424 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Alan McKinnon]

On Sun, 11 Mar 2012 15:37:26 -0400 (EDT)
Daddy <daddy@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Daddy]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]



On March 11, 2012 at 4:27 PM Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On Sun, 11 Mar 2012 15:37:26 -0400 (EDT)
> Daddy <daddy@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.mckinnon@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.

[-- Attachment #2: Type: text/html, Size: 2375 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Alan McKinnon]

On Sun, 11 Mar 2012 19:07:37 -0400 (EDT)
Daddy <daddy@happypenguincomputers.com> wrote:

> 
> 
> On March 11, 2012 at 4:27 PM Alan McKinnon <alan.mckinnon@gmail.com>
> wrote:
> 
> > On Sun, 11 Mar 2012 15:37:26 -0400 (EDT)
> > Daddy <daddy@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.mckinnon@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[pk]

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

[Walter Dnes]

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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Daddy]

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]




On March 11, 2012 at 3:28 PM Walter Dnes <waltdnes@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 <waltdnes@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

[-- Attachment #2: Type: text/html, Size: 4363 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[pk]

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

[covici]

Daddy <daddy@happypenguincomputers.com> wrote:

> On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@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 <waltdnes@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
         covici@ccs.covici.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[pk]

On 2012-03-20 20:49, covici@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

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 4183 bytes --]

On Mar 21, 2012 2:52 AM, <covici@ccs.covici.com> wrote:
>
> Daddy <daddy@happypenguincomputers.com> wrote:
>
> > On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@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 <waltdnes@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,

[-- Attachment #2: Type: text/html, Size: 6023 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 3700 bytes --]

On Mar 11, 2012 6:30 PM, "Daddy" <daddy@happypenguincomputers.com> wrote:
>
> On March 11, 2012 at 5:09 AM Walter Dnes <waltdnes@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 <waltdnes@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,

[-- Attachment #2: Type: text/html, Size: 5278 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5

[Walter Dnes]

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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6

[Walter Dnes]

  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've also found one
situation where I need to take one extra step to run without udev.  I
have a laptop with a Radeon GPU that requires a binary blob for the
video driver.  emerging radeon-ucode downloads a whole slew of binary
blobs, to support umpteen different models.  If I leave all the binary
blobs in the library directory, the kernwl needs udev to figure out
which one of the many binary blobs to load.  If I remove all the other
binary blobs, and leave only the correct one in the library directory,
it loads automatically.

  There is one more imperfect sanity check you can run to check for udev
dependancy if none of the above apply...

a) add the line
sys-fs/udev
to /etc/portage/package.mask

b) execute the 2 commands
emerge -pv system
emerge -pv world

c) if the only errors you get are for not being able to re-install udev
as required by virtual/dev-manager-0, you can proceed to the next stage,
Otherwise, remove the "sys-fs/udev" line from /etc/portage/package.mask
and forget about mdev.

  Proceed here only if the above stages don't find any udev
dependancies.

  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.

3 b) 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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6

[J. Roeleveld]

On Tue, March 13, 2012 9:45 pm, Walter Dnes wrote:
>   I've also found one
> situation where I need to take one extra step to run without udev.  I
> have a laptop with a Radeon GPU that requires a binary blob for the
> video driver.  emerging radeon-ucode downloads a whole slew of binary
> blobs, to support umpteen different models.  If I leave all the binary
> blobs in the library directory, the kernwl needs udev to figure out
> which one of the many binary blobs to load.  If I remove all the other
> binary blobs, and leave only the correct one in the library directory,
> it loads automatically.

Wouldn't a good solution be to have the ebuild modified to only install
those binary blobs you actually need?
Eg. similar to how apache or sane modules are configured?

--
Joost

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6

[Walter Dnes]

On Wed, Mar 14, 2012 at 02:15:52PM +0100, J. Roeleveld wrote

> Wouldn't a good solution be to have the ebuild modified to only
> install those binary blobs you actually need?  Eg. similar to how
> apache or sane modules are configured?

  The tarball on the AMD website has all the binary blobs bundled
together.  The ebuild simply downloads the tarball and extracts it to
the correct library directory.  You could do it manually.  The problem
with separate ebuilds is that one ebuild would be replaced with a couple
of dozen ebuilds, or one ebuild with a couple of dozen custom USE flags.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 3:43 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Mar 14, 2012 at 02:15:52PM +0100, J. Roeleveld wrote
>
>> Wouldn't a good solution be to have the ebuild modified to only
>> install those binary blobs you actually need?  Eg. similar to how
>> apache or sane modules are configured?
>
>  The tarball on the AMD website has all the binary blobs bundled
> together.  The ebuild simply downloads the tarball and extracts it to
> the correct library directory.  You could do it manually.  The problem
> with separate ebuilds is that one ebuild would be replaced with a couple
> of dozen ebuilds, or one ebuild with a couple of dozen custom USE flags.

You could use an use-expand variable, like INPUT_DEVICES or
VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds
like the smart thing to do.

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 6

[Walter Dnes]

On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote

> You could use an use-expand variable, like INPUT_DEVICES or
> VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds
> like the smart thing to do.

  The VIDEO_CARDS variable might be "RADEON", but there are many
different levels of Radeon GPU cards, each requiring its own specific
binary blob.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Mar 15, 2012 7:04 AM, "Walter Dnes" <waltdnes@waltdnes.org> wrote:
>
> On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote
>
> > You could use an use-expand variable, like INPUT_DEVICES or
> > VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds
> > like the smart thing to do.
>
>  The VIDEO_CARDS variable might be "RADEON", but there are many
> different levels of Radeon GPU cards, each requiring its own specific
> binary blob.
>

So, detail it down... e.g. RADEON-HD-4650, RADEON-HD-6530, etc. Kind of
like the xtables-addons package.

Rgds,

[-- Attachment #2: Type: text/html, Size: 787 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 6

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 5:59 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Mar 14, 2012 at 04:09:33PM -0600, Canek Pel??ez Vald??s wrote
>
>> You could use an use-expand variable, like INPUT_DEVICES or
>> VIDEO_CARDS for xorg-drivers, or DRACUT_MODULES for dracut. It sounds
>> like the smart thing to do.
>
>  The VIDEO_CARDS variable might be "RADEON", but there are many
> different levels of Radeon GPU cards, each requiring its own specific
> binary blob.

I meant coming up with a new use-expand variable, like RADEON_FIRMWARE
or something like that.

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 :-(

[Alan Mackenzie]

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

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

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

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

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

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

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

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

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

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


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

> sys-apps/busybox static mdev

>    Now, "emerge busybox"


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

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

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

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

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

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

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

Done

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

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

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

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

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

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

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

Help would be appreciated.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[pk]

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 - failure :-(

[Walter Dnes]

On Mon, Mar 12, 2012 at 09:24:32AM +0000, 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-9999::gentoo (masked by: package.mask, missing keyword)
/etc/portage/package.mask:

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

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Walter.

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

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

> waltdnes@d530 ~ $ emerge -pv lvm2

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

> Calculating dependencies... done!

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Walter Dnes]

On Mon, Mar 12, 2012 at 09:24:32AM +0000, Alan Mackenzie wrote

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

1) Add the line...

sys-fs/udev

to /etc/portage/package.mask.


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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

Hi, Walter.

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

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

> 1) Add the line...

> sys-fs/udev

> to /etc/portage/package.mask.

DONE.

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

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

:-)  I would have forgotten about that.

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).


[-- Attachment #2: mdev.tar.gz --]
[-- Type: application/octet-stream, Size: 6532 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Walter Dnes]

On Tue, Mar 13, 2012 at 01:05:34PM +0000, Alan Mackenzie wrote

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

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

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Walter,

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 1:47 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hello, Walter,
>
> On Tue, Mar 13, 2012 at 03:00:52PM -0400, Walter Dnes wrote:
>> On Tue, Mar 13, 2012 at 01:05:34PM +0000, Alan Mackenzie wrote
>
>> > I also did "2> {system,world}.err".  system.err was empty.  I've included
>> > world.err in the enclosed tarball.
>
>>   From your error listing, it looks like lvm2, kde, and gnome (including
>> the XFCE subset) require udev.  Ouch.
>
> :-)  This cannot be the case.  Otherwise somebody would have said.  Hmm.
> What we could do with is a "requires xdev", for x in (m u).  I've
> forgotten what that's called in portage.
>
> There are surely lots of packages marked "need udev" which don't really
> need it at all.  I mean, are there any programs which need precisely
> udev to work, as opposed to a populated /dev?
>
> I mean, what does udev give me that mdev won't?  That's not really a
> rhetorical question.  What potential benefits am I throwing away by
> converting to mdev?

From my desktop:

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

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

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 :-(

[Bruce Hill, Jr.]

On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" <caneko@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 bull<manure>. <:-)}

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 :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
<daddy@happypenguincomputers.com> wrote:
>
>
>
> On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" <caneko@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 :-(

[Bruce Hill, Jr.]

On March 13, 2012 at 5:22 PM "Canek Peláez Valdés" <caneko@gmail.com>
wrote:

> On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
> <daddy@happypenguincomputers.com> wrote:
> >
> >
> >
> > On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" <caneko@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 :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 3:35 PM, Bruce Hill, Jr.
<daddy@happypenguincomputers.com> wrote:
>
>
>
> On March 13, 2012 at 5:22 PM "Canek Peláez Valdés" <caneko@gmail.com>
> wrote:
>
>> On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
>> <daddy@happypenguincomputers.com> wrote:
>> >
>> >
>> >
>> > On March 13, 2012 at 4:27 PM "Canek Peláez Valdés" <caneko@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 :-(

[Bruce Hill, Jr.]

On March 13, 2012 at 5:49 PM "Canek Peláez Valdés" <caneko@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 :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 4:36 PM, Bruce Hill, Jr.
<daddy@happypenguincomputers.com> wrote:
>
>
>
> On March 13, 2012 at 5:49 PM "Canek Peláez Valdés" <caneko@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 :-(

[Alan McKinnon]

On Tue, 13 Mar 2012 17:35:05 -0400 (EDT)
"Bruce Hill, Jr." <daddy@happypenguincomputers.com> wrote:

> 
> 
> 
> On March 13, 2012 at 5:22 PM "Canek Peláez Valdés" <caneko@gmail.com>
> wrote:
> 
> > On Tue, Mar 13, 2012 at 2:54 PM, Bruce Hill, Jr.
> > <daddy@happypenguincomputers.com> wrote:
> > >
> > >
> > >
> > > On March 13, 2012 at 4:27 PM "Canek Peláez Valdés"
> > > <caneko@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.mckinnon@gmail.com

[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Nicolas Sebrecht]

The 13/03/12, Bruce Hill, Jr. wrote:
> 
> 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!

This is not FUD. And more importantly, what Canek says is certainly true.

In the past, the kernel was handling devices alone.  Since udev, the
possibility for userland programs to hook themselves in this process
became very easy.

Some of them have use this feature very early but we can reasonably
think the work is not totally achieved. Also, developers write code
given the context at the time it is written. But the changing context
doesn't necessarily imply other programs to be rewritten at the same
time.  Once the context changed, we can reasonably think that currently
"working code not going to be hacked soon" will be rewritten in the longer
run to take advantage of this udev facility.

Pointing to this fact is not FUD. I'd say it is nice analysis which
could even help the current udev -> mdev effort by providing a different
picture of the landscape.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Canek,

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

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

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

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

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

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

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

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

> >>From my desktop:

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

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

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

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

> You will lose those with mdev.

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

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

Thanks for the reply.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote:

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Neil.

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

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

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

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

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

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

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

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

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

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

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

> -- 
> Neil Bothwick

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hello, Neil.
>
> On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote:
>> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote:
>
>> > But I really meant what functionality udev has that mdev lacks.  For
>> > example, mdev this morning recognised my USB stick being inserted, and
>> > created /dev/sdc for it.
>
>> udev does a *lot* more than that, for example the persistent naming of
>> network interfaces. More significantly, it can run programs based on
>> device rules.
>
> This is where I start getting unhappy.  Is there any need for this
> blurring?  Having device nodes is essential to a linux system, and
> some programs use these nodes.  Why must they be mashed together into a
> tasteless mush?  Is there some advantage to this I haven't twigged yet?
>
>> For example, usb_modeswitch installs a udev rule to switch a 3G USB
>> modem from CD to modem mode, without which it won't work.
>
> Same question as above: why does that switching have to be done via the
> device node system rather than via the driver.  Isn't that what drivers
> are for?
>
>> That's fine when you plug it into a running system, but when you boot
>> with it plugged in, it can trip over itself because the usb_modeswitch
>> executable is in /usr/sbin.
>
> Er, that's a different discussion altogether.  ;-)
>
>> You could use this to argue that /usr should be mounted before udev is
>> started, but you could just as well use it to argue that udev should not
>> be trying to run such rules at the boot runlevel.
>
> Or that udev shouldn't have "rules".  I still don't understand the basic
> concept driving this thing.  My HDDs don't need rules - they just need a
> mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
> drivers built into my kernel.
>
> Am I being stupid?  Despite your example above, I still don't see what
> udev is about, why it's necessary, or even why it's advantageous.

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

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 :-(

[Alan Mackenzie]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ .... ]

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <acm@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 <acm@muc.de> wrote:
>> > Hello, Neil.
>
>> > On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote:
>> >> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote:
>
>> >> > But I really meant what functionality udev has that mdev lacks.  For
>> >> > example, mdev this morning recognised my USB stick being inserted, and
>> >> > created /dev/sdc for it.
>
>> >> udev does a *lot* more than that, for example the persistent naming of
>> >> network interfaces. More significantly, it can run programs based on
>> >> device rules.
>
>> > This is where I start getting unhappy.  Is there any need for this
>> > blurring?  Having device nodes is essential to a linux system, and
>> > some programs use these nodes.  Why must they be mashed together into a
>> > tasteless mush?  Is there some advantage to this I haven't twigged yet?
>
>> >> For example, usb_modeswitch installs a udev rule to switch a 3G USB
>> >> modem from CD to modem mode, without which it won't work.
>
>> > Same question as above: why does that switching have to be done via the
>> > device node system rather than via the driver.  Isn't that what drivers
>> > are for?
>
>> >> That's fine when you plug it into a running system, but when you boot
>> >> with it plugged in, it can trip over itself because the usb_modeswitch
>> >> executable is in /usr/sbin.
>
>> > Er, that's a different discussion altogether.  ;-)
>
>> >> You could use this to argue that /usr should be mounted before udev is
>> >> started, but you could just as well use it to argue that udev should not
>> >> be trying to run such rules at the boot runlevel.
>
>> > Or that udev shouldn't have "rules".  I still don't understand the basic
>> > concept driving this thing.  My HDDs don't need rules - they just need a
>> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
>> > drivers built into my kernel.
>
>> > Am I being stupid?  Despite your example above, I still don't see what
>> > udev is about, why it's necessary, or even why it's advantageous.
>
>> IMHO, the thing that most people are missing is the fact that neither
>> udev nor Linux "got complicated". The computing world itself "got
>> complicated".
>
> Not really.  It's been getting more complicated since long before I
> starting working in it in 1980.  Nothing's changed there.
>
>> We have Linux running in the same beige machines it has been running
>> since 1991, but it also runs in TVs, tablets, cellphones, fridges,
>> cars, ebook readers, and (soon enough, I'm sure) the kitchen sink.
>> This devices behave very differently from our old and beloved beige
>> boxen.
>
> Not at the level of needing device nodes under /dev and drivers connected
> to them, they haven't.
>
>> They need to handle lots of different hardware comming and going, via
>> USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future.
>
> Yes.  That's why there's a generic facility for building arbitrary
> drivers into a kernel.  That's not new either.
>
>> The principal idea behind udev, is that we *don't* kown (we *can't*
>> know) what hardware this or that machine is gonna have at some point.
>> And we want the machine (and the new hardware) to "just work" when
>> they are connected.
>
> Huh?  What's that to do with udev?  You're talking at far too high a
> level of abstraction.  The new hardware will "just work" if there are the
> correct drivers built in.  That's as true of udev as it is of mdev as it
> is of the old static /dev with mknod.

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; 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?

I'm not, and 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.

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.

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

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 :-(

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

On Mar 14, 2012 7:10 AM, "Canek Peláez Valdés" <caneko@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,

[-- Attachment #2: Type: text/html, Size: 2087 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

Hello, Canek

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Mar 14, 2012 10:20 PM, "Alan Mackenzie" <acm@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,

[-- Attachment #2: Type: text/html, Size: 1614 bytes --]

RE: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Mike Edenfield]

From: Pandu Poluan [mailto:pandu@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 :-(

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie <acm@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 <acm@muc.de> wrote:
>
>> > The new hardware will "just work" if there are the correct drivers
>> >built in.  That's as true of udev as it is of mdev as it is of the old
>> >static /dev with mknod.
>
>> No, it is not. You are letting out the sine qua non of the matter: the
>> device has to be built, *and the /dev file should exists*. I hope you
>> are not suggesting that we put *ALL* the possible files under /dev,
>> because that was the idea before devfs, and it doesn't work *IN
>> GENERAL*.
>
> Previously you made appropriate /dev entries with mknod, giving the
> device major and minor numbers as parameters.  This appeared to work in
> general - I'm not aware of any device it didn't work for.

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 solution that in the end will not solve the
general problem.

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.

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.

>> 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.

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.

Again, this is OpenSource: go nuts with any problem you find
"interesting" (I really don't understand why solving a particular case
of the general problem will be more interesting that solving the
former, but that is maybe the Computer Scientist in me).

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.

>> 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.

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.

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.

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 :-(

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 5783 bytes --]

On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@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 busybox
too complex.

[1] http://lists.busybox.net/pipermail/busybox/2011-September/076689.html

Again, it's a matter of perspective. We can work around the problem by
having the emulated libudev call mdev indirectly via an "mdev helper
program", thus not needing mdev to be a kitchen sink.

In fact, a post [2] slightly tangential to the thread of the above post,
did just that: provide a way for mdev to be able to link onto netlink
without having to make mdev a daemon.

[2] http://lists.busybox.net/pipermail/busybox/2011-September/076740.html

Rgds,

[-- Attachment #2: Type: text/html, Size: 6787 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@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 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.

I'm not defending anything; just stating my opinion. You are free to
disagree, of course.

>> 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.

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.

> 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 busybox too
> complex.
>
> [1] http://lists.busybox.net/pipermail/busybox/2011-September/076689.html
>
> Again, it's a matter of perspective. We can work around the problem by
> having the emulated libudev call mdev indirectly via an "mdev helper
> program", thus not needing mdev to be a kitchen sink.
>
> In fact, a post [2] slightly tangential to the thread of the above post, did
> just that: provide a way for mdev to be able to link onto netlink without
> having to make mdev a daemon.
>
> [2] http://lists.busybox.net/pipermail/busybox/2011-September/076740.html

You keep saying is easy/simple/doable; code talks. Right now, the guy
doing some coding and not only talking (Walter) says
GNOME/KDE/XFCE/LVM2 doesn't work with mdev. *Maybe* they could be made
to work with mdev, but someone has to actually *write the code* for
that to happen. Until then, talking is easy.

Right now, mdev is not enough, period. Maybe we can (as you yourself
say) "work around" the "problem", but that is work that someone has to
do.

If someone is willing (and able) to do it, good for him/she/them. I'm
sticking with udev, and if at some point mdev does everything udev
does right now, I again bet a beer that the first would be as complex
as the second.

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 :-(

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 6007 bytes --]

On Mar 15, 2012 1:22 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>
> On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pandu@poluan.info> wrote:
> >
> > On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@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 rename+symlink.

> If someone is willing (and able) to do it, good for him/she/them. I'm
> sticking with udev, and if at some point mdev does everything udev
> does right now, I again bet a beer that the first would be as complex
> as the second.
>

You are *totally* missing the point.

The point was never to make mdev as complex as udev.

The point was to give people option by *not* requiring udev, but only
virtual/device-manager.

Users no longer have to choose between two dichotomies, i.e., the
omnipotent udev vs the simplistic mdev. Instead, they can choose between
the bloated udev, or the lean mdev which *already can* cater for more
complex behavior if necessary.

Rgds,

[-- Attachment #2: Type: text/html, Size: 7228 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On Mar 15, 2012 2:24 AM, "Pandu Poluan" <pandu@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,

[-- Attachment #2: Type: text/html, Size: 760 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 1:24 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Mar 15, 2012 1:22 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>>
>> On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pandu@poluan.info> wrote:
>> >
>> > On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@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 lived through the OSS -> ALSA
transition, the GNOME 1.0 -> GNOME 1.2 -> GNOME 2.0 -> GNOME 3.0
transition, the xine -> Mplayer -> Totem transition, the HAL -> no-HAL
transition, and (of course) the  mknod -> devfs -udev transition.

I'm willing to bet yet another beer that udev will not have the fate HAL had.

>> > 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.

So, easily fix it. I'm not using it anyhow.

>> 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.

I'm not slandering anyone; I'm just stating my opinion. mdev cannot do
what udev does, and I believe the mdev developers agree with that
(certainly Walt does). I don't see why that's "slandering".

Don't take it personal man, relax.

>> >> 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'?

No, udev solves the general problem, mdev not. That's it.

> Sounds like a fanboy rant to me :-)

If you say so. Not the case, actually.

>> 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 rename+symlink.

Then do it. My "slandering" (so you call it) should not matter.

>> If someone is willing (and able) to do it, good for him/she/them. I'm
>> sticking with udev, and if at some point mdev does everything udev
>> does right now, I again bet a beer that the first would be as complex
>> as the second.
>>
>
> You are *totally* missing the point.

I believe I'm not.

> The point was never to make mdev as complex as udev.

You *are* missing my point. My prediction is that if mdev ever handles
all the cases udev does, mdev will be as complex as udev. I could be
wrong, of course. But again, educated guess ;)

> The point was to give people option by *not* requiring udev, but only
> virtual/device-manager.

And good for them.

> Users no longer have to choose between two dichotomies, i.e., the omnipotent
> udev vs the simplistic mdev. Instead, they can choose between the bloated
> udev, or the lean mdev which *already can* cater for more complex behavior
> if necessary.

Bluetooth anybody?

And relax man, this is friendly dicussion, not  religious rethoric.

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 :-(

[pk]

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 :-(

[Michael Mol]

On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie <acm@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 <acm@muc.de> wrote:
>>
>>> > The new hardware will "just work" if there are the correct drivers
>>> >built in.  That's as true of udev as it is of mdev as it is of the old
>>> >static /dev with mknod.
>>
>>> No, it is not. You are letting out the sine qua non of the matter: the
>>> device has to be built, *and the /dev file should exists*. I hope you
>>> are not suggesting that we put *ALL* the possible files under /dev,
>>> because that was the idea before devfs, and it doesn't work *IN
>>> GENERAL*.
>>
>> Previously you made appropriate /dev entries with mknod, giving the
>> device major and minor numbers as parameters.  This appeared to work in
>> general - I'm not aware of any device it didn't work for.
>
> 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 server, nor typical embedded devices like
>> routers.
>
> Alan, the "vast majority" of Linux users right now are phone users.

Phone users are _excellent_ examples of embedded environments. You
have a static hardware set, where you can predict darn near everything
about it that you might possibly need during a boot sequence. You're
not expected or intended to cope with boot failures. Your bluetooth
earpiece and input devices can wait until the OS has loaded.

This is exactly the kind of environment where I would expect udev to
_not_ be necessary during boot.

> 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 can only assume you've run a server. I expect you currently run at
least one. If you haven't, then you _really_ have no standing to argue
that server environments are irrelevant; you'd be belying a massive
lack of understanding of systemic, practical and operational context.
I can't _imagine_ you expect the client/server architecture of the
Internet to go away in the near future. You're very explicitly talking
about sacrificing Linux's efficiency in a server environment in favor
of The General Case, which is a case which should only be needed once
the system has already booted.

We used to joke that emacs would be a great operating system if only
it had drivers. From your arguments and positions, it's looking like
udev is setting itself to be the next target of similar jokes.


>
>>> 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].

See my argument above about static, predictable hardware,
strictly-defined boot process and clear stages of operation.

>
>>  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 solution that in the end will not solve the
> general problem.

Honestly, you're too dead set on finding a solution to the general
problem, because to solve the general problem, you must redefine
reality to cope with the limits of your theory. In order to handle the
burden of your general-case-software, hardware itself must become more
powerful and more expensive, which in turn will lead to greater
complexity for your general case. Old hardware, no longer capable of
running the general case software, even though it's a specific-case
device, is wastefully discarded.

>
> 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.
>
> 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, phones and tablets are simple cases.

>
>>> 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.
>
> 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 here is the biggest reason I get frustrated with you. You say "go
ahead and try, you're wasting your effort. You're going to fail.
Everyone will leave you behind." It's an incredibly negative,
aggressive attitude which isn't geared toward finding a solution, but
is rather geared at reducing the problem.

>
> Again, this is OpenSource: go nuts with any problem you find
> "interesting" (I really don't understand why solving a particular case
> of the general problem will be more interesting that solving the
> former, but that is maybe the Computer Scientist in me).

That's exactly what it is. I have a _lot_ of interest in (and respect
for) computer science[1], but I also have several years of practical,
real-world software development. I have the privilege of being allowed
to see and participate in both the realms of theory and of practice.

I'm not the smartest or most knowledgeable guy on this mailing list,
but I think I might know enough to say that, yes, you have too strong
a focus on the general case.


>
> 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.

The fundamental problem, as I see it, is that udev's role currently
encompasses both runtime hotplug events and boot-time
responsibilities. Those need to be separated. How? I don't have a
quick or easy answer, but that's where I see the systemic problem.
(And, no, I won't suggest that HAL is the solution.)

>
>>> 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.
>
> 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.

And I think you're thinking too big. Every case you would reach for to
cover with your general case, there will be a case just outside your
reach. At some point, you need to express limits. Limits are fine.
Limits can be practical. Heck, reasonable limits make practice easier,
because known constraints help one predict the behavior of the system.

>
> 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.

BTW, you've put yourself into a niche here; you want a general-purpose
platform in embedded devices, but that's not the environment you've
argued the majory of Linux users exist in. I agree the majority of
Linux users are probably running Android at this point. They're not
running a general-purpose platform.

>
> To accomplish that we need udev; mdev it's just not enough.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

[1] Don't believe me? I started and continue to operate and fund
Rosetta Code with the specific and ongoing interest in providing a
tool which helps to improve the state of the art. (Watching and
learning from a mix of practical and academic expert users of hundreds
of different programming languages has been a great experience, too.)

-- 
:wq

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 12:09 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie <acm@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 <acm@muc.de> wrote:
>>>
>>>> > The new hardware will "just work" if there are the correct drivers
>>>> >built in.  That's as true of udev as it is of mdev as it is of the old
>>>> >static /dev with mknod.
>>>
>>>> No, it is not. You are letting out the sine qua non of the matter: the
>>>> device has to be built, *and the /dev file should exists*. I hope you
>>>> are not suggesting that we put *ALL* the possible files under /dev,
>>>> because that was the idea before devfs, and it doesn't work *IN
>>>> GENERAL*.
>>>
>>> Previously you made appropriate /dev entries with mknod, giving the
>>> device major and minor numbers as parameters.  This appeared to work in
>>> general - I'm not aware of any device it didn't work for.
>>
>> 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 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.


>>
>>>> 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.
>
> Phone users are _excellent_ examples of embedded environments. You
> have a static hardware set, where you can predict darn near everything
> about it that you might possibly need during a boot sequence. You're
> not expected or intended to cope with boot failures. Your bluetooth
> earpiece and input devices can wait until the OS has loaded.
>
> This is exactly the kind of environment where I would expect udev to
> _not_ be necessary during boot.

The phones/tablets of now have everything but a "static hardware set".
The connect (wirelessly usually) with a lot of things, and they have
USB and SD besides. So I would expect udev to *be* necessary with
them.

I'm still wainting for someone to tell me how mdev handles bluetooth.

>> 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 can only assume you've run a server. I expect you currently run at
> least one. If you haven't, then you _really_ have no standing to argue
> that server environments are irrelevant; you'd be belying a massive
> lack of understanding of systemic, practical and operational context.
> I can't _imagine_ you expect the client/server architecture of the
> Internet to go away in the near future. You're very explicitly talking
> about sacrificing Linux's efficiency in a server environment in favor
> of The General Case, which is a case which should only be needed once
> the system has already booted.

"sacrificing Linux's efficiency in a server environment"? What are you
talking about? I run my servers with udev... *and* systemd. Have you
tried it? Are you *sure* it's less efficient, or it seems so to you
"in theory"?

More complex doesn't mean less efficient: again, look at the fuel
injection analogy. It's incredible complex, but it gives you *more*
fuel efficiency.

The general  solution is *specially* important for the server case.
Kay and Lennart work for RedHat, and be sure RHEL will have udev and
systemd at some point. And guess what? I'm willing to bet another beer
that it would be more efficient.

> We used to joke that emacs would be a great operating system if only
> it had drivers. From your arguments and positions, it's looking like
> udev is setting itself to be the next target of similar jokes.

Maybe it's coincidence, but I still use Emacs ;)

Read the last mail from Greg KH in the -dev list: more coupling is
what most of the devs are looking for, because *it solves more cases*
of the general problem.

>
>>
>>>> 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].
>
> See my argument above about static, predictable hardware,
> strictly-defined boot process and clear stages of operation.

Again, if it's simpler/easier, why has anybody implemented it? And
please, don't say "mdev", because (as I have said), it doesn't work
*right now* for all my use cases. When it does, I keep betting that it
would be as complex as udev.

>>
>>>  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 solution that in the end will not solve the
>> general problem.
>
> Honestly, you're too dead set on finding a solution to the general
> problem, because to solve the general problem, you must redefine
> reality to cope with the limits of your theory. In order to handle the
> burden of your general-case-software, hardware itself must become more
> powerful and more expensive, which in turn will lead to greater
> complexity for your general case. Old hardware, no longer capable of
> running the general case software, even though it's a specific-case
> device, is wastefully discarded.

What are you talking about man? The "general problem", by definition,
includes old hardware. That's why it's "general".

I think you guys are not seeing the forest because of all the trees.

>
>>
>> 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.
>>
>> 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, phones and tablets are simple cases.

OK; call me when they use mdev.

>>
>>>> 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.
>>
>> 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 here is the biggest reason I get frustrated with you. You say "go
> ahead and try, you're wasting your effort. You're going to fail.
> Everyone will leave you behind." It's an incredibly negative,
> aggressive attitude which isn't geared toward finding a solution, but
> is rather geared at reducing the problem.

I'm just stating my opinion; if you find it "negative", well sorry.
Disagree with me if you want, but (obviously) I don't think or see the
problem as you guys. I'm not being "negative"; I'm just call'em as I
see'em.

And besides, it matters not what I say or don't say, because what
matters is the *code*. And the code of udev works right now in the
general case; mdev (as cute hack as it could be) doesn't. That's all
what I'm saying.


>>
>> Again, this is OpenSource: go nuts with any problem you find
>> "interesting" (I really don't understand why solving a particular case
>> of the general problem will be more interesting that solving the
>> former, but that is maybe the Computer Scientist in me).
>
> That's exactly what it is. I have a _lot_ of interest in (and respect
> for) computer science[1], but I also have several years of practical,
> real-world software development. I have the privilege of being allowed
> to see and participate in both the realms of theory and of practice.
>
> I'm not the smartest or most knowledgeable guy on this mailing list,
> but I think I might know enough to say that, yes, you have too strong
> a focus on the general case.

Wellm, yes. That's what I have been saying.

>
>>
>> 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.
>
> The fundamental problem, as I see it, is that udev's role currently
> encompasses both runtime hotplug events and boot-time
> responsibilities. Those need to be separated. How? I don't have a
> quick or easy answer, but that's where I see the systemic problem.
> (And, no, I won't suggest that HAL is the solution.)

Again, read about devfs. Tighly coupling is the path the developers
(in general) are taking. I agree with them.


>
>>
>>>> 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.
>>
>> 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.
>
> And I think you're thinking too big.

Thank you.

> Every case you would reach for to
> cover with your general case, there will be a case just outside your
> reach. At some point, you need to express limits. Limits are fine.
> Limits can be practical. Heck, reasonable limits make practice easier,
> because known constraints help one predict the behavior of the system.

I know limits. udev has a lot of limitations; but it can do anything
mdev can, and more. I'm not talking from a pure theoretical POV.

>>
>> 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.
>
> BTW, you've put yourself into a niche here; you want a general-purpose
> platform in embedded devices, but that's not the environment you've
> argued the majory of Linux users exist in. I agree the majority of
> Linux users are probably running Android at this point. They're not
> running a general-purpose platform.

And the devs are planning on changing that ;) That's the whole point
of all this udev mess.


>>
>> To accomplish that we need udev; mdev it's just not enough.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> [1] Don't believe me? I started and continue to operate and fund
> Rosetta Code with the specific and ongoing interest in providing a
> tool which helps to improve the state of the art. (Watching and
> learning from a mix of practical and academic expert users of hundreds
> of different programming languages has been a great experience, too.)

I believe you. I'm finishing my PhD in Computer Science, but I have
years of experience administering servers and coding as professional
programmer. And I strongly disagree with how you guys see things.

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 :-(

[Michael Mol]

On Wed, Mar 14, 2012 at 2:45 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Mar 14, 2012 at 12:09 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie <acm@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 <acm@muc.de> wrote:
>>>>
>>>>> > The new hardware will "just work" if there are the correct drivers
>>>>> >built in.  That's as true of udev as it is of mdev as it is of the old
>>>>> >static /dev with mknod.
>>>>
>>>>> No, it is not. You are letting out the sine qua non of the matter: the
>>>>> device has to be built, *and the /dev file should exists*. I hope you
>>>>> are not suggesting that we put *ALL* the possible files under /dev,
>>>>> because that was the idea before devfs, and it doesn't work *IN
>>>>> GENERAL*.
>>>>
>>>> Previously you made appropriate /dev entries with mknod, giving the
>>>> device major and minor numbers as parameters.  This appeared to work in
>>>> general - I'm not aware of any device it didn't work for.
>>>
>>> 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 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 of the dodo too, but that's besides the point.

No, it's really not. Replace 'BIOS' with 'UEFI' or whatever you like;
you still need _something_ to handle initial hardware initialization
which has device-specific knowledge. And if your UEFI firmware
supports Bluetooth, whether the OS supports it or not becomes a moot
point; you can use a legacy support mechanism such as the ones that
allowed me to use USB keyboards in DOS. (Yes, I've done that.)

> 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.

Go look at the spec. Go look at the list of existing Bluetooth
profiles. Sit down and _study_ this thing which you keep holding up as
an example. You've had someone else do all the work for you, and I
don't think you understand how much of a mess it really is. I would
have loved to set up a huge amount of stuff piped and routed via
bluetooth as a PAN, but outside of a few core profiles with de facto
support, nothing really interoperates well.

>
>
>>>
>>>>> 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.
>>
>> Phone users are _excellent_ examples of embedded environments. You
>> have a static hardware set, where you can predict darn near everything
>> about it that you might possibly need during a boot sequence. You're
>> not expected or intended to cope with boot failures. Your bluetooth
>> earpiece and input devices can wait until the OS has loaded.
>>
>> This is exactly the kind of environment where I would expect udev to
>> _not_ be necessary during boot.
>
> The phones/tablets of now have everything but a "static hardware set".
> The connect (wirelessly usually) with a lot of things, and they have
> USB and SD besides. So I would expect udev to *be* necessary with
> them.

For boot?

Also, you want udev to handle wifi? Bluetooth, I could see, but wifi
belongs elsewhere; AFAIK, the kernel doesn't send hotplug events for
visible networks.

USB (client mode, not host mode) and SD, sure, you want a hotplug
handler. But that's not necessary during boot, and there's nothing
dynamic about them apart from they're either active or they're not.
They'll have static hardware positions. You won't be adding and
removing them.

USB host most (which few mobile devices have, but some do) is a
different animal, but, again, not something typical (your mainstream,
mass market, majority of Linux users) mobile and embedded devices need
to care about at boot.

>
> I'm still wainting for someone to tell me how mdev handles bluetooth.

I'm still waiting for you to explain why bluetooth makes sense for
your boot-failed device.

>
>>> 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 can only assume you've run a server. I expect you currently run at
>> least one. If you haven't, then you _really_ have no standing to argue
>> that server environments are irrelevant; you'd be belying a massive
>> lack of understanding of systemic, practical and operational context.
>> I can't _imagine_ you expect the client/server architecture of the
>> Internet to go away in the near future. You're very explicitly talking
>> about sacrificing Linux's efficiency in a server environment in favor
>> of The General Case, which is a case which should only be needed once
>> the system has already booted.
>
> "sacrificing Linux's efficiency in a server environment"? What are you
> talking about? I run my servers with udev... *and* systemd. Have you
> tried it? Are you *sure* it's less efficient, or it seems so to you
> "in theory"?

The more complicated the software, the more RAM, CPU and disk it must
consume. Ergo, by increasing resource usage in one area, you decrease
its availability in another area.

There's the theory. And, yes, I do run udev on my servers, because my
servers aren't such that I want to poke and prod with alternatives
quite yet. Someday, I very probably will run mdev, because I see the
memory, CPU and RAM counters for the three udev instances on my
server, and I want those resources for something else, because I
_care_ about the performance of my server. And I'd care even more if I
was trying to fit things inside 2MB of RAM instead of 2GB or 4GB of
RAM.

>
> More complex doesn't mean less efficient: again, look at the fuel
> injection analogy. It's incredible complex, but it gives you *more*
> fuel efficiency.

In a dynamic system, perhaps. A server is certainly not a dynamic
system. The boot sequence of my phone does not need to be a dynamic
system. The boot sequence of my tablet does not need to be a dynamic
system.

>
> The general  solution is *specially* important for the server case.
> Kay and Lennart work for RedHat, and be sure RHEL will have udev and
> systemd at some point. And guess what? I'm willing to bet another beer
> that it would be more efficient.

I think you and I are at some strong disagreement by which we count efficiency.

>
>> We used to joke that emacs would be a great operating system if only
>> it had drivers. From your arguments and positions, it's looking like
>> udev is setting itself to be the next target of similar jokes.
>
> Maybe it's coincidence, but I still use Emacs ;)
>
> Read the last mail from Greg KH in the -dev list: more coupling is
> what most of the devs are looking for, because *it solves more cases*
> of the general problem.

Sure. People like integration, because standardizing interoperability
of discrete pieces in a system requires cooperation, and is thus more
difficult. Making a monolith, though, almost invariably makes
maintenance more difficult in the long term. Going back to cars, I
can't use an engine from a Ford in a Hyundai, because their interfaces
aren't standardized. I can take a video card from a Dell and put it in
a Lenovo, though, because those interfaces _are_ standardized.

>
>>
>>>
>>>>> 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].
>>
>> See my argument above about static, predictable hardware,
>> strictly-defined boot process and clear stages of operation.
>
> Again, if it's simpler/easier, why has anybody implemented it?

Not sure exactly what you're asking/saying. What is "it" here? udev?
Because someone didn't like the status quo and came up with a
solution. And then the solution snowballed into something massive and
nowhere near as simple and elegant as its initial versions.

Yes, udev was once a pretty decent piece of software, but it's
reaching to cover too many different use paradigms, and *that's*
what's making it so complex. But people didn't really care until udev
decided that it was going to step away from trying to be
self-contained, and declared restrictions on the hosting environment.

*That* is taking a direct movement away from The General Case; they
redefined The General Case to something that was easier for them to
cope with.

> And
> please, don't say "mdev", because (as I have said), it doesn't work
> *right now* for all my use cases. When it does, I keep betting that it
> would be as complex as udev.

I'd bet it won't. And shouldn't. Because your use cases are outside
its target. (And, actually, your use cases are outside what your
hardware was designed to do. By forcing it out of its niche, you're
injecting inelegence into your own system.)

>
>>>
>>>>  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 solution that in the end will not solve the
>>> general problem.
>>
>> Honestly, you're too dead set on finding a solution to the general
>> problem, because to solve the general problem, you must redefine
>> reality to cope with the limits of your theory. In order to handle the
>> burden of your general-case-software, hardware itself must become more
>> powerful and more expensive, which in turn will lead to greater
>> complexity for your general case. Old hardware, no longer capable of
>> running the general case software, even though it's a specific-case
>> device, is wastefully discarded.
>
> What are you talking about man? The "general problem", by definition,
> includes old hardware. That's why it's "general".

But the more complex you make the software, the more difficult it
becomes to fit it into old hardware.

>
> I think you guys are not seeing the forest because of all the trees.

I think you're forgetting that a forest is made of trees.

>
>>
>>>
>>> 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.
>>>
>>> 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, phones and tablets are simple cases.
>
> OK; call me when they use mdev.
>
>>>
>>>>> 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.
>>>
>>> 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 here is the biggest reason I get frustrated with you. You say "go
>> ahead and try, you're wasting your effort. You're going to fail.
>> Everyone will leave you behind." It's an incredibly negative,
>> aggressive attitude which isn't geared toward finding a solution, but
>> is rather geared at reducing the problem.
>
> I'm just stating my opinion; if you find it "negative", well sorry.
> Disagree with me if you want, but (obviously) I don't think or see the
> problem as you guys. I'm not being "negative"; I'm just call'em as I
> see'em.
>
> And besides, it matters not what I say or don't say, because what
> matters is the *code*. And the code of udev works right now in the
> general case; mdev (as cute hack as it could be) doesn't. That's all
> what I'm saying.

Every time someone starts actually doing something about it, you tell
them they're wasting their time, and that they're doomed, but,
whatever, it's their time to waste.

That's pretty negative and condescending, and is polarizing the issue.


>
>
>>>
>>> Again, this is OpenSource: go nuts with any problem you find
>>> "interesting" (I really don't understand why solving a particular case
>>> of the general problem will be more interesting that solving the
>>> former, but that is maybe the Computer Scientist in me).
>>
>> That's exactly what it is. I have a _lot_ of interest in (and respect
>> for) computer science[1], but I also have several years of practical,
>> real-world software development. I have the privilege of being allowed
>> to see and participate in both the realms of theory and of practice.
>>
>> I'm not the smartest or most knowledgeable guy on this mailing list,
>> but I think I might know enough to say that, yes, you have too strong
>> a focus on the general case.
>
> Wellm, yes. That's what I have been saying.

You're saying you're too focused? I haven't seen that except for one paragraph.

>
>>
>>>
>>> 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.
>>
>> The fundamental problem, as I see it, is that udev's role currently
>> encompasses both runtime hotplug events and boot-time
>> responsibilities. Those need to be separated. How? I don't have a
>> quick or easy answer, but that's where I see the systemic problem.
>> (And, no, I won't suggest that HAL is the solution.)
>
> 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.

>
>
>>
>>>
>>>>> 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.
>>>
>>> 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.
>>
>> And I think you're thinking too big.
>
> Thank you.
>
>> Every case you would reach for to
>> cover with your general case, there will be a case just outside your
>> reach. At some point, you need to express limits. Limits are fine.
>> Limits can be practical. Heck, reasonable limits make practice easier,
>> because known constraints help one predict the behavior of the system.
>
> I know limits. udev has a lot of limitations; but it can do anything
> mdev can, and more. I'm not talking from a pure theoretical POV.

You're thinking about algorithmic limits. I'm talking about practical
limits like bytes, counts and CPU cycles.

>
>>>
>>> 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.
>>
>> BTW, you've put yourself into a niche here; you want a general-purpose
>> platform in embedded devices, but that's not the environment you've
>> argued the majory of Linux users exist in. I agree the majority of
>> Linux users are probably running Android at this point. They're not
>> running a general-purpose platform.
>
> And the devs are planning on changing that ;) That's the whole point
> of all this udev mess.

You're getting impossible to argue with. You've gone from

"most people using Linux are using Linux via Android"

to

"well, I don't want to use my embedded devices as embedded devices, I
want something more general than Android"

to

"the udev developers are working on changing embedded devices from
being embedded devices to being general-purpose devices."

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.

-- 
:wq

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 1:41 PM, Michael Mol <mikemol@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 :-(

[Dale]

Canek Peláez Valdés wrote:
> On Wed, Mar 14, 2012 at 1:41 PM, Michael Mol <mikemol@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 :-(

[pk]

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 :-(

[Bruce Hill, Jr.]

On March 14, 2012 at 1:22 PM "Canek Peláez Valdés" <caneko@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 :-(

[Canek Peláez Valdés]

On Fri, Mar 16, 2012 at 10:20 PM, Bruce Hill, Jr.
<daddy@happypenguincomputers.com> wrote:
>
>
>
> On March 14, 2012 at 1:22 PM "Canek Peláez Valdés" <caneko@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 :-(

[Alan McKinnon]

On Fri, 16 Mar 2012 22:27:02 -0600
Canek Peláez Valdés <caneko@gmail.com> wrote:

> On Fri, Mar 16, 2012 at 10:20 PM, Bruce Hill, Jr.
> <daddy@happypenguincomputers.com> wrote:
> >
> >
> >
> > On March 14, 2012 at 1:22 PM "Canek Peláez Valdés"
> > <caneko@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Bruce Hill, Jr.]

On March 17, 2012 at 10:20 AM Alan McKinnon <alan.mckinnon@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.mckinnon@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 :-(

[Walter Dnes]

On Wed, Mar 14, 2012 at 03:16:20PM +0000, 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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Tanstaafl]

On 2012-03-13 8:07 PM, Canek Peláez Valdés <caneko@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 :-(

[Michael Mol]

On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2012-03-13 8:07 PM, Canek Peláez Valdés <caneko@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 :-(

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

On Mar 14, 2012 10:30 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl <tanstaafl@libertytrek.org>
wrote:
> > On 2012-03-13 8:07 PM, Canek Peláez Valdés <caneko@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,

[-- Attachment #2: Type: text/html, Size: 2685 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Joost Roeleveld]

On Wednesday, March 14, 2012 10:59:30 PM Pandu Poluan wrote:
> On Mar 14, 2012 10:30 PM, "Michael Mol" <mikemol@gmail.com> wrote:
> > On Wed, Mar 14, 2012 at 11:20 AM, Tanstaafl <tanstaafl@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 :-(

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Joost Roeleveld]

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 :-(

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

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...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan McKinnon]

On Fri, 16 Mar 2012 22:33:55 +0000
Neil Bothwick <neil@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan McKinnon]

On Mon, 19 Mar 2012 23:23:51 +0000
Neil Bothwick <neil@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.mckinnon@gmail.com

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Mike Edenfield]

 From: Alan Mackenzie [mailto:acm@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 :-(

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2923 bytes --]

On Tue, 13 Mar 2012 22:20:19 +0000, Alan Mackenzie wrote:

> > udev does a *lot* more than that, for example the persistent naming of
> > network interfaces. More significantly, it can run programs based on
> > device rules.
> 
> This is where I start getting unhappy.  Is there any need for this
> blurring?  Having device nodes is essential to a linux system, and
> some programs use these nodes.  Why must they be mashed together into a
> tasteless mush?  Is there some advantage to this I haven't twigged yet?

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

> > For example, usb_modeswitch installs a udev rule to switch a 3G USB
> > modem from CD to modem mode, without which it won't work.
> 
> Same question as above: why does that switching have to be done via the
> device node system rather than via the driver.  Isn't that what drivers
> are for?

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

> > 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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Alan Mackenzie]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> -- 
> Neil Bothwick

> How do I set my laser printer to stun?

How about a picture of Marilyn Monroe?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 4878 bytes --]

On Tue, 13 Mar 2012 23:43:54 +0000, 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 USB>RS232
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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Stroller]

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 :-(

[Alan Mackenzie]

Good evening, Stroller.

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

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

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

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

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

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

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

The same could be done for network cards.

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

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

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

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

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

Yes.

> Stroller.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Walter Dnes]

On Wed, Mar 14, 2012 at 05:56:34PM +0000, 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 <waltdnes@waltdnes.org>

Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Graham Murray]

Stroller <stroller@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.