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

» Linux Archive

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


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-14-2012, 05:35 AM
Sylvain Alain
 
Default udev <-> mdev

Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that project a while ago.
https://github.com/slashbeast/mdev-like-a-boss

I think that it's actually working pretty good on his box.
Some Coredevs from Funtoo are actually running with that stuff.
Sylvain


2012/7/13 William Hubbs <williamh@gentoo.org>

On Fri, Jul 13, 2012 at 08:13:43PM -0400, Walter Dnes wrote:

> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote

> > On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:

> > > mdev would need to switch to the netlink hotplug interface.

> >

> > I think that's quite unlikely, since mdev is not a daemon. Perhaps by

> > the time /proc/sys/kernel/hotplug is gone, mdev advocates will have

> > settled on some early udev fork. [1]

>

> * Do you realize this would effectively kill linux in the embedded

> device area? *Udev, even without the systemd code, is simply to large

> for embedded devices.



What about using devtmpfs alone?



William



--
Salut
alp
Sylvain
 
Old 07-14-2012, 06:13 AM
Graham Murray
 
Default udev <-> mdev

"Walter Dnes" <waltdnes@waltdnes.org> writes:

> On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
>> On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao@gentoo.org> wrote:
>> > mdev would need to switch to the netlink hotplug interface.
>>
>> I think that's quite unlikely, since mdev is not a daemon. Perhaps by
>> the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
>> settled on some early udev fork. [1]
>
> Do you realize this would effectively kill linux in the embedded
> device area? Udev, even without the systemd code, is simply to large
> for embedded devices.

But surely most embedded devices do not need hotplug functionality, they
have a known, fixed, set of devices. So should static nodes in /dev/ not
be sufficient?
 
Old 07-14-2012, 06:30 AM
Canek Peláez Valdés
 
Default udev <-> mdev

On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain <d2racing911@gmail.com> wrote:
> Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
> project a while ago.
>
> https://github.com/slashbeast/mdev-like-a-boss
>
> I think that it's actually working pretty good on his box.
>
> Some Coredevs from Funtoo are actually running with that stuff.

I don't think anybody has ever suggested that it's not possible to run
mdev instead of udev: as Walter has proved, it is indeed possible.

The question Olivier and William are making is (if I understand
correctly) if you don't need the features of udev, then why not use
only devtmpfs. I think everyone agrees that mdev doesn't have (and
probably never will nor want) all the features that udev has.

Seeing all the trouble some people have taken to make their systems
work with mdev just to avoid having to use an initramfs, I really
wonder how much effort it would have taken the simple task of learning
one step more when updating kernels and switch to use an initramfs.

Then again, everyone is entitled to work in the features (or
anti-features) they want. It is FLOSS after all.

Just the 0.02 ${CURRENCY} of a happy udev/systemd user (I'm really
happy the merged the two project trees).

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 07-14-2012, 11:33 AM
Duncan
 
Default udev <-> mdev

Graham Murray posted on Sat, 14 Jul 2012 07:13:56 +0100 as excerpted:

> "Walter Dnes" <waltdnes@waltdnes.org> writes:
>
>> Do you realize this would effectively kill linux in the embedded
>> device area? Udev, even without the systemd code, is simply to large
>> for embedded devices.
>
> But surely most embedded devices do not need hotplug functionality, they
> have a known, fixed, set of devices. So should static nodes in /dev/ not
> be sufficient?

Well, there's (kernel-side) devfs as well, as others have mentioned.

Meanwhile, "embedded" can mean different things to different users of the
term. I expect few would argue that onboard boot devices on embedded are
likely to change, but there's a lot of (arguably embedded) devices with
USB-host support these days, and some form of dynamic device-nodes, even
if it's just devfs, can make that much more flexible and easier to deal
with.

What's interesting is the potential on such devices for USB-based
storage, displays, sound, net and HID, blurring the definition of
"embedded" even further, altho one would hope nobody tries to connect all
of those up to the same host USB port (via hub) at the same time as I can
just imagine the bandwidth management headaches trying to do so, thus
implying 2-3 USB host-ports, minimum.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 07-14-2012, 09:02 PM
Peter Stuge
 
Default udev <-> mdev

Canek Peláez Valdés wrote:
> Seeing all the trouble some people have taken to make their systems
> work with mdev just to avoid having to use an initramfs, I really
> wonder how much effort it would have taken the simple task of learning
> one step more when updating kernels and switch to use an initramfs.

I think udev, systemd, and initramfs are orthogonal concepts.

FWIW I've built more or less deeply embedded Linux systems with
Gentoo and without, for years.

I stopped using init scripts long before I started using Gentoo in 2004.

systemd is in most regards a significant improvement over everything
that was previously available.

The few regards where it isn't are outweighed fairly easily by the
value of same process management both on desktop Linux and embedded
Linux.

On deeply embedded systems with say 2 or 4 Mbyte flash I might choose
something other than systemd however. As was pointed out, such a
system may also not need to be very dynamic, so losing udev is not
neccessarily a problem. If they do need to be dynamic, then will have
to make some room for udev as well.

Anyone who tries to argue that initramfs would be good for me to
have on my systems should brace themselves for a mouthful of foul
swedish language coming their way!


//Peter
 
Old 07-14-2012, 09:29 PM
Canek Peláez Valdés
 
Default udev <-> mdev

On Sat, Jul 14, 2012 at 4:02 PM, Peter Stuge <peter@stuge.se> wrote:
[snip]
> Anyone who tries to argue that initramfs would be good for me to
> have on my systems should brace themselves for a mouthful of foul
> swedish language coming their way!

I don't think anyone has argued it's "good" for anyone. An initramfs
it's just now the only supported way (by udev and systemd) to have a
separated /usr partition.

If your /usr is in the same partition as /, then udev and systemd
supports your configuration *without* an initramfs. I have it like
that in a couple of servers, and actually I only use an initramfs in
my laptop and desktop because I like plymouth.

If your /usr is in a separate partition as /, and you don't want to
use an initramfs, you're free to do so. Only then udev (and systemd,
if you use it) will not support your configuration, and any problem
you encounter will be ignored in their mailing lists/bugzillas.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 07-14-2012, 09:52 PM
Peter Stuge
 
Default udev <-> mdev

Canek Peláez Valdés wrote:
> An initramfs it's just now the only supported way (by udev and
> systemd) to have a separated /usr partition.

Yes sure. I considered separate partitions in the 90s, let's just
say that I don't see the problem that many on the internet cry about.

Using multiple filesystems in a system allows doing very nice things,
but /usr /var /whatever is waay too clumsy, to do the nice things
there needs to be more cleverness, which we're not neccessarily ready
for just yet.


//Peter
 
Old 07-14-2012, 11:38 PM
Duncan
 
Default udev <-> mdev

Canek Peláez Valdés posted on Sat, 14 Jul 2012 16:29:19 -0500 as
excerpted:

> If your /usr is in the same partition as /, then udev and systemd
> supports your configuration *without* an initramfs. I have it like that
> in a couple of servers, and actually I only use an initramfs in my
> laptop and desktop because I like plymouth.
>
> If your /usr is in a separate partition as /, and you don't want to use
> an initramfs, you're free to do so. Only then udev (and systemd,
> if you use it) will not support your configuration, and any problem you
> encounter will be ignored in their mailing lists/bugzillas.


BTW, any "gentooish" documentation out there on rootfs as tmpfs, with
/etc and the like mounted on top of it, operationally ro, rw remounted
for updates?

That's obviously going to take an initr*, which I've never really
understood to the point I'm comfortable with my ability to recover from
problems so I've not run one since my Mandrake era, but that's a status
that can change, and what with the /usr move and some computer problems I
just finished dealing with, I've been thinking about the possibility
lately. So if there's some good docs on the topic someone can point me
at, I'd be grateful. =:^)

I'm aware of the issues with /etc/mtab and have googled a bit on the
workarounds, but that looks like a decent amount of work, and if I'm
going to do that, I might as well invest the time and do it right, initr*,
full tmpfs rootfs with everything non-volatile mounted on top, the whole
shebang!

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 07-14-2012, 11:57 PM
Rich Freeman
 
Default udev <-> mdev

On Sat, Jul 14, 2012 at 7:38 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> BTW, any "gentooish" documentation out there on rootfs as tmpfs, with
> /etc and the like mounted on top of it, operationally ro, rw remounted
> for updates?
>
> That's obviously going to take an initr*, which I've never really
> understood to the point I'm comfortable with my ability to recover from
> problems so I've not run one since my Mandrake era, but that's a status
> that can change, and what with the /usr move and some computer problems I
> just finished dealing with, I've been thinking about the possibility
> lately. So if there's some good docs on the topic someone can point me
> at, I'd be grateful. =:^)

I doubt anybody has tried it, so you'll have to experiment.

I imagine you could do it with a dracut module. There is already a
module that will parse a pre-boot fstab (/etc/fstab.sys). The trick
is that you need to create the root filesystem and the mountpoints
within it first. The trick will be how dracut handles not specifying
a root filesystem.

However, if anything I think the future trend will be towards having
everything back on the root filesystem, since with btrfs you can set
quotas on subvolumes and have a lot more flexibility in general, which
you start to lose if you chop up your disks. However, I guess you
could still have one big btrfs filesystem and mount individual
subvolumes out of it onto your root. I'm not really sure what that
gets you. Having the root itself be a subvolume does have benefits,
since you can then snapshot it and easily boot back off a snapshot if
something goes wrong.

Rich
 
Old 07-15-2012, 01:02 AM
Duncan
 
Default udev <-> mdev

Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted:

> On Sat, Jul 14, 2012 at 7:38 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> BTW, any "gentooish" documentation out there on rootfs as tmpfs, with
>> /etc and the like mounted on top of it, operationally ro, rw remounted
>> for updates?
>>
>> That's obviously going to take an initr*, which I've never really
>> understood to the point I'm comfortable with my ability to recover from
>> problems so I've not run one since my Mandrake era, but that's a status
>> that can change, and what with the /usr move and some computer problems
>> I just finished dealing with, I've been thinking about the possibility
>> lately. So if there's some good docs on the topic someone can point me
>> at, I'd be grateful. =:^)
>
> I doubt anybody has tried it, so you'll have to experiment.

"Anybody" /anybody/, or "anybody" on gentoo? FWIW, there are people
running it in general (IIRC much of the discussion was on Debian, some on
Fedora/RH), but I didn't see anything out there written from a gentoo
perspective. Gentoo-based docs/perspective does help, as one isn't
constantly having to translate binary-based assumptions into "gentooese",
but there's enough out there in general that a suitably determined/
motivated person at the usual experienced gentoo user level should be
able to do it, without having to be an /extreme/ wizard. But so far I've
not been /that/ motivated, and if there was gentoo docs available, it
would bring the barriers down far enough that I likely /would/ then have
the (now lower) required motivation/determination.

Just looking for that shortcut, is all. =:^)

> I imagine you could do it with a dracut module. There is already a
> module that will parse a pre-boot fstab (/etc/fstab.sys). The trick is
> that you need to create the root filesystem and the mountpoints within
> it first. The trick will be how dracut handles not specifying a root
> filesystem.

While I do know dracut is an initr* helper, you just made me quite aware
of just how much research I'd have to do on the topic. =:^ I wasn't
aware dracut even /had/ modules, while you're referring to them with the
ease of familiarity...

> However, if anything I think the future trend will be towards having
> everything back on the root filesystem, since with btrfs you can set
> quotas on subvolumes and have a lot more flexibility in general, which
> you start to lose if you chop up your disks. However, I guess you could
> still have one big btrfs filesystem and mount individual subvolumes out
> of it onto your root. I'm not really sure what that gets you. Having
> the root itself be a subvolume does have benefits, since you can then
> snapshot it and easily boot back off a snapshot if something goes wrong.

The big problem with btrfs subvolumes from my perspective is that they're
still all on a single primary filesystem, and if that filesystem develops
problems... all your eggs/data are in one big basket, good luck if the
bottom drops out of it!

One lesson I've had drilled into my head repeatedly over now two decades
of computer experience... don't put all your data in one basket! It's a
personal policy that's saved my @$$ more than a few times over the years.

Even with raid, when I first setup md/raid, I set it up as a nice big
(partitioned) raid, with a second (similarly partitioned) raid as a
backup. With triple-digits gigs of data (this was pre-terabyte-drive
era), a system-crash related re-add and resync would take /hours/.

So when I rebuilt the setup, I created over a dozen (including working
and backup copies of many of them) individual raids, each in its own set
of partitions on the physical devices, some raids of which were further
partitioned, some not, but only the media raid (and its backup) were
anything like 100 gigs, and with many of even the working raids (plus all
backups) not even activated for normal operation unless I was actually
working on whatever data was on that raid, and in general even most of
the the assembled raids with rw mounting not actively writing at the time
of a crash, re-add and resync tended to be seconds or minutes, not hours.

So I'm about as strong a partitioning-policy advocate as you'll get, tho
I do keep everything that the pm installs, along with the installation
database (so /etc, /usr, /var, but not for instance /var/log or /usr/src,
which are mountpoints), on the same (currently) rootfs of 8-ish gigs,
with a backup root partition (actually two of them now) that I can point
the kernel at from grub, if the working rootfs breaks for some reason.
So the separate /usr/ thing hasn't affected me at all, because /usr/ is
on rootfs.

But as I said I had some computer hardware issues recently, and they made
me aware of just how nice it'd be to have that rootfs mounted read-only
for normal operation -- no fsck/log-replay needed on read-only-at-time-of-
crash mounts! =:^)

So I'm pondering just how hard it would be...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 

Thread Tools




All times are GMT. The time now is 08:19 PM.

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