Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Jan 9, 2012 3:24 PM, pk pete...@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,
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
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 waltd...@waltdnes.org
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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.binCAYMAN_pfp.bin JUNIPER_pfp.bin SUMO2_me.bin BARTS_me.binCAYMAN_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.binPALM_pfp.bin SUMO_pfp.bin CAICOS_mc.bin CEDAR_rlc.binR600_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 waltd...@waltdnes.org
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
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 waltd...@waltdnes.org
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Thu, Jan 5, 2012 at 03:21, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan pa...@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
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
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. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Thu, 5 Jan 2012 16:07:04 +0700 Pandu Poluan pa...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Thu, 05 Jan 2012 09:17:23 +0100
pk pete...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
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
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 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 signature.asc Description: PGP signature
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
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
On Jan 5, 2012 7:10 PM, Alan McKinnon alan.mckin...@gmail.com wrote:
On Thu, 05 Jan 2012 09:17:23 +0100
pk pete...@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,
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Jan 5, 2012 11:44 PM, pk pete...@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,
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Thu, 05 Jan 2012 16:50:45 +0100
pk pete...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Thu, 5 Jan 2012 15:52:04 + Neil Bothwick n...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Thu, Jan 5, 2012 at 1:02 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Thu, 05 Jan 2012 16:50:45 +0100 pk pete...@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
On Thu, Jan 5, 2012 at 5:01 AM, Nicolas Sebrecht nsebre...@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
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Thursday 05 Jan 2012 18:20:16 Michael Mol wrote: On Thu, Jan 5, 2012 at 1:02 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Thu, 05 Jan 2012 16:50:45 +0100 pk pete...@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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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. signature.asc Description: PGP signature
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Thu, Jan 5, 2012 at 5:08 PM, Nicolas Sebrecht nicolas.s-...@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
On Thu, 5 Jan 2012 16:38:20 -0500 Michael Mol mike...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
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
On Jan 6, 2012 8:50 AM, Dale rdalek1...@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,
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
Pandu Poluan wrote: On Jan 6, 2012 8:50 AM, Dale rdalek1...@gmail.com mailto:rdalek1...@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
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Jan 6, 2012 10:04 AM, pk pete...@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,
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Jan 4, 2012 6:19 AM, Dale rdalek1...@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,
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluan pa...@poluan.info wrote: On Jan 4, 2012 6:19 AM, Dale rdalek1...@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
Canek Peláez Valdés wrote: On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluanpa...@poluan.info wrote: On Jan 4, 2012 6:19 AM, Dalerdalek1...@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
On Wed, Jan 4, 2012 at 6:33 PM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Wed, Jan 4, 2012 at 6:35 AM, Pandu Poluanpa...@poluan.info wrote: On Jan 4, 2012 6:19 AM, Dalerdalek1...@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
On Wed, 4 Jan 2012 18:49:29 -0500 Michael Mol mike...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Thu, 05 Jan 2012 08:30:52 +0100 pk pete...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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 waltd...@waltdnes.org
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Tue, Jan 3, 2012 at 17:04, Walter Dnes waltd...@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
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
On Jan 3, 2012 7:35 PM, Nicolas Sebrecht nsebre...@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,
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Tue, 3 Jan 2012 13:32:09 +0100 Nicolas Sebrecht nsebre...@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.mckin...@gmail.com
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht nsebre...@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
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
The 03/01/12, Pandu Poluan wrote: On Tue, Jan 3, 2012 at 20:13, Nicolas Sebrecht nsebre...@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
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
On Tue, 3 Jan 2012 15:31:20 +0100 Nicolas Sebrecht nsebre...@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.mckin...@gmail.com
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
Alan McKinnon wrote: On Tue, 3 Jan 2012 15:31:20 +0100 Nicolas Sebrechtnsebre...@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
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 waltd...@waltdnes.org
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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 signature.asc Description: PGP signature
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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
[gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
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 waltd...@waltdnes.org
Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev; version 3
On Dec 2, 2011 2:50 AM, Walter Dnes waltd...@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,
