Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

udev <-> mdev

 

 

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


axs at gentoo

Jul 12, 2012, 6:37 AM

Post #1 of 45 (1282 views)
Permalink
udev <-> mdev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/07/12 11:40 PM, Walter Dnes wrote:
> On Wed, Jul 11, 2012 at 09:49:18AM -0400, Michael Mol wrote
>> Walter Dnes (very active over in gentoo-user) has put a lot of
>> work into testing and documenting mdev as an alternative for
>> udev. There's been a good deal of success there, up to and
>> including it working with GNOME 2. The work's been documented on
>> the wiki: https://wiki.gentoo.org/wiki/Mdev
>
> I'm now testing automount under mdev. No GUI required. I hope to
> have a wiki page up soon.
>
> As for GNOME and KDE, they're trying to become OS's in their own
> right. What can I say? There are a lot of alternative desktop
> environments and window managers. That's my target.
>

Out of curiosity, since mdev is (i assume) more than complete enough
to handle mounting, would it be possible to initially start with mdev
and then hand over control to udev (if there was a need for udev, that
is) , to avoid initramfs with separate /usr ?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+0x0ACgkQ2ugaI38ACPB1zwD/UTRcKHG91/q9RyovsvChaPWE
voF+oOAl5mE6A6hoN5UA/12KAC5XHModBZqNkWYuMqpB2q67t4fWHhp/w5lL7u7Z
=3uUp
-----END PGP SIGNATURE-----


waltdnes at waltdnes

Jul 12, 2012, 1:07 PM

Post #2 of 45 (1284 views)
Permalink
Re: udev <-> mdev [In reply to]

On Thu, Jul 12, 2012 at 09:37:33AM -0400, Ian Stakenvicius wrote

First a disclaimer... I am not a C programmer, let alone a developer.
I feel like I've been dragged into this kicking and screaming in order
to save the Gentoo that I remember from a few years ago.

> Out of curiosity, since mdev is (i assume) more than complete enough
> to handle mounting, would it be possible to initially start with mdev
> and then hand over control to udev (if there was a need for udev, that
> is) , to avoid initramfs with separate /usr ?

I think that's exactly how initramfs itself works. You might be able
to use an initrd instead of initramfs. See Zac Medico's posting at...
http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
That was the clue that got me started on replacing udev with mdev.

Once you have psuedo-filesystems and partitions mounted, you need to
shut down mdev and start up udev. And make sure that
/proc/sys/kernel/hotplug points to udev.

If you want to get fancy, you can boot from a separate small boot
partition, or for that matter a USB key. Then either chroot or
pivot_root into the udev environment. For pivot_root man pages see
http://linux.die.net/man/8/pivot_root and
http://linux.die.net/man/2/pivot_root

--
Walter Dnes <waltdnes [at] waltdnes>


williamh at gentoo

Jul 12, 2012, 3:29 PM

Post #3 of 45 (1256 views)
Permalink
Re: udev <-> mdev [In reply to]

Hi all,

On Thu, Jul 12, 2012 at 04:07:41PM -0400, Walter Dnes wrote:
> On Thu, Jul 12, 2012 at 09:37:33AM -0400, Ian Stakenvicius wrote
>
> First a disclaimer... I am not a C programmer, let alone a developer.
> I feel like I've been dragged into this kicking and screaming in order
> to save the Gentoo that I remember from a few years ago.
>
> > Out of curiosity, since mdev is (i assume) more than complete enough
> > to handle mounting, would it be possible to initially start with mdev
> > and then hand over control to udev (if there was a need for udev, that
> > is) , to avoid initramfs with separate /usr ?
>
> I think that's exactly how initramfs itself works. You might be able
> to use an initrd instead of initramfs. See Zac Medico's posting at...
> http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
> That was the clue that got me started on replacing udev with mdev.

initrd is deprecated and has been for a long time; you should use
initramfs.

> Once you have psuedo-filesystems and partitions mounted, you need to
> shut down mdev and start up udev. And make sure that
> /proc/sys/kernel/hotplug points to udev.

If you are using udev, /proc/sys/kernel/hotplug should be empty; do not
point this to udev.

Thanks,

William


1i5t5.duncan at cox

Jul 12, 2012, 10:58 PM

Post #4 of 45 (1260 views)
Permalink
Re: udev <-> mdev [In reply to]

William Hubbs posted on Thu, 12 Jul 2012 17:29:31 -0500 as excerpted:

>> And make sure that
>> /proc/sys/kernel/hotplug points to udev.
>
> If you are using udev, /proc/sys/kernel/hotplug should be empty; do not
> point this to udev.

Yes. I've not changed that setting from whatever the default is, and I
guess udev moved its hook out from there quite some time ago so it's
pointing at nothing, but having that actually point to something is known
in kernel circles to lead to a lot of unnecessary grief. They're
seriously thinking about (and may be planning on) removing that option
from the kernel entirely, to keep people configuring their first kernels
from getting themselves in trouble, but of course that's now part of the
kernel/userspace interface, so it isn't allowed to just disappear like
kernel/kernel interfaces can. At minimum they'd likely have to have it
on the deprecation and removal schedule for awhile. (I've not checked to
see if it's there already.)

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


waltdnes at waltdnes

Jul 13, 2012, 1:04 PM

Post #5 of 45 (1244 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 05:58:25AM +0000, Duncan wrote

> They're seriously thinking about (and may be planning on) removing
> that option from the kernel entirely, to keep people configuring
> their first kernels from getting themselves in trouble, but of course
> that's now part of the kernel/userspace interface, so it isn't allowed
> to just disappear like kernel/kernel interfaces can. At minimum
> they'd likely have to have it on the deprecation and removal schedule
> for awhile. (I've not checked to see if it's there already.)

So what happens to people using mdev? Do we have to switch from
Linu-x to Lenna-x?

--
Walter Dnes <waltdnes [at] waltdnes>


ryao at gentoo

Jul 13, 2012, 1:12 PM

Post #6 of 45 (1246 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On 07/13/2012 04:04 PM, Walter Dnes wrote:
> On Fri, Jul 13, 2012 at 05:58:25AM +0000, Duncan wrote
>
>> They're seriously thinking about (and may be planning on) removing
>> that option from the kernel entirely, to keep people configuring
>> their first kernels from getting themselves in trouble, but of course
>> that's now part of the kernel/userspace interface, so it isn't allowed
>> to just disappear like kernel/kernel interfaces can. At minimum
>> they'd likely have to have it on the deprecation and removal schedule
>> for awhile. (I've not checked to see if it's there already.)
>
> So what happens to people using mdev? Do we have to switch from
> Linu-x to Lenna-x?
>

mdev would need to switch to the netlink hotplug interface.
Attachments: signature.asc (0.88 KB)


mk at dee

Jul 13, 2012, 3:49 PM

Post #7 of 45 (1244 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao <ryao [at] gentoo> 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]

[1] http://archives.gentoo.org/gentoo-dev/msg_72b87bf5888d6f6e675429dbfe420db5.xml

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte


waltdnes at waltdnes

Jul 13, 2012, 5:13 PM

Post #8 of 45 (1250 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

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 [at] gentoo> 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.

--
Walter Dnes <waltdnes [at] waltdnes>


caneko at gmail

Jul 13, 2012, 5:36 PM

Post #9 of 45 (1254 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 7:13 PM, Walter Dnes <waltdnes [at] waltdnes> 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 [at] gentoo> 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.

The guys from ProFUSION would disagree with you:

http://profusion.mobi/

It is a "a software development company focused on embedded systems",
and several of its employees contribute code and ideas for systemd, so
they also use udev. For embedded systems.

The idea that udev "is simply to large" is simply incorrect, I believe.

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


mikemol at gmail

Jul 13, 2012, 5:40 PM

Post #10 of 45 (1247 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 8:13 PM, Walter Dnes <waltdnes [at] waltdnes> 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 [at] gentoo> 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.

I'll venture a guess the solution will be to create a shim daemon
which turns around and launches udev.

--
:wq


mk at dee

Jul 13, 2012, 5:41 PM

Post #11 of 45 (1241 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes [at] waltdnes> wrote:
> 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's “too large”? Udev already looks pretty small to me (116k udevd,
50k libudev, 500k resident memory), and I didn't even try compiling it
with all extra features switched off. If that's too large for an
embedded device, does that device really need (or can handle) anything
more than devtmpfs?

--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte


waltdnes at waltdnes

Jul 13, 2012, 6:10 PM

Post #12 of 45 (1240 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote

> I'll venture a guess the solution will be to create a shim daemon
> which turns around and launches udev.

A quicker-and-dirtier solution would be to create a shim daemon that
runs under the the name "udev", and passes all calls to /sbin/mdev.

--
Walter Dnes <waltdnes [at] waltdnes>


mikemol at gmail

Jul 13, 2012, 6:15 PM

Post #13 of 45 (1237 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 9:10 PM, Walter Dnes <waltdnes [at] waltdnes> wrote:
> On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote
>
>> I'll venture a guess the solution will be to create a shim daemon
>> which turns around and launches udev.
>
> A quicker-and-dirtier solution would be to create a shim daemon that
> runs under the the name "udev", and passes all calls to /sbin/mdev.

... and that's what I thought I'd typed. -.-


--
:wq


tester at gentoo

Jul 13, 2012, 6:21 PM

Post #14 of 45 (1243 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, 2012-07-13 at 21:10 -0400, Walter Dnes wrote:
> On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote
>
> > I'll venture a guess the solution will be to create a shim daemon
> > which turns around and launches udev.
>
> A quicker-and-dirtier solution would be to create a shim daemon that
> runs under the the name "udev", and passes all calls to /sbin/mdev.

Seriously, mdev is a just a bad and now useless hack, it does nothing
more than using devtmpfs. You do not need udev for a very simple system.
If you system is a bit more complicated, than udev is what you want. It
works fine on millions of shipping devices.

And on any new embedded platform, one should seriously think about using
systemd too. It is very lean, replaces most of the giant, unmaintainable
shellscripts that you find in many devices with smaller compiled code,
and was designed to be a good fit for embedded devices.

--
Olivier Crête
tester [at] gentoo
Gentoo Developer
Attachments: signature.asc (0.19 KB)


waltdnes at waltdnes

Jul 13, 2012, 6:22 PM

Post #15 of 45 (1244 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes [at] waltdnes> wrote:
> > 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's ?too large?? Udev already looks pretty small to me (116k udevd,
> 50k libudev, 500k resident memory), and I didn't even try compiling it
> with all extra features switched off. If that's too large for an
> embedded device, does that device really need (or can handle) anything
> more than devtmpfs?

What does "equery depgraph" show for udev? Since I don't have udev
installed, I can't check it here.

--
Walter Dnes <waltdnes [at] waltdnes>


mikemol at gmail

Jul 13, 2012, 6:28 PM

Post #16 of 45 (1255 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes <waltdnes [at] waltdnes> wrote:
> On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
>> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes [at] waltdnes> wrote:
>> > 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's ?too large?? Udev already looks pretty small to me (116k udevd,
>> 50k libudev, 500k resident memory), and I didn't even try compiling it
>> with all extra features switched off. If that's too large for an
>> embedded device, does that device really need (or can handle) anything
>> more than devtmpfs?
>
> What does "equery depgraph" show for udev? Since I don't have udev
> installed, I can't check it here.


sys-fs/udev-114:
[ 0] sys-fs/udev-114
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-115-r1:
[ 0] sys-fs/udev-115-r1
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-119:
[ 0] sys-fs/udev-119
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-124-r1:
[ 0] sys-fs/udev-124-r1
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-124-r2:
[ 0] sys-fs/udev-124-r2
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-141:
[ 0] sys-fs/udev-141
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-141-r1:
[ 0] sys-fs/udev-141-r1
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-146-r1:
[ 0] sys-fs/udev-146-r1
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/acl-2.2.51
[ 1] sys-apps/usbutils-004
[ 1] virtual/libusb-0
[ 1] sys-apps/pciutils-3.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-149:
[ 0] sys-fs/udev-149
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/acl-2.2.51
[ 1] sys-apps/usbutils-004
[ 1] virtual/libusb-0
[ 1] sys-apps/pciutils-3.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] app-text/tree-1.6.0-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-151-r4:
[ 0] sys-fs/udev-151-r4
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/acl-2.2.51
[ 1] sys-apps/usbutils-004
[ 1] virtual/libusb-0
[ 1] sys-apps/pciutils-3.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] app-text/tree-1.6.0-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-164-r2:
[ 0] sys-fs/udev-164-r2
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/acl-2.2.51
[ 1] sys-apps/usbutils-004
[ 1] virtual/libusb-0
[ 1] sys-apps/pciutils-3.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] app-text/tree-1.6.0-r1
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-171-r5:
[ 0] sys-fs/udev-171-r5
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/acl-2.2.51
[ 1] dev-libs/glib-2.30.3
[ 1] dev-libs/gobject-introspection-1.30.0-r2
[ 1] virtual/libusb-0
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] app-text/tree-1.6.0-r1
[ 1] sys-apps/usbutils-004
[ 1] sys-apps/hwids-99999999
[ 1] sys-apps/pciutils-3.1.9-r2
[ 1] sys-apps/pciutils-3.1.9-r1
[ 1] sys-apps/pciutils-3.1.7
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-171-r6:
[ 0] sys-fs/udev-171-r6
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] dev-libs/gobject-introspection-1.30.0-r2
[ 1] virtual/libusb-0
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] app-text/tree-1.6.0-r1
[ 1] sys-apps/usbutils-004
[ 1] sys-apps/hwids-99999999
[ 1] sys-apps/pciutils-3.1.9-r2
[ 1] sys-apps/pciutils-3.1.9-r1
[ 1] sys-apps/pciutils-3.1.7
[ 1] sys-apps/baselayout-2.1-r1

sys-fs/udev-182-r2:
[ 0] sys-fs/udev-182-r2
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] dev-libs/gobject-introspection-1.30.0-r2
[ 1] sys-apps/kmod-9999
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] dev-util/gtk-doc-1.18-r1
[ 1] sys-apps/usbutils-004
[ 1] sys-apps/pciutils-3.1.9-r1
[ 1] sys-apps/pciutils-3.1.7
[ 1] sys-fs/udev-init-scripts-9999

sys-fs/udev-182-r3:
[ 0] sys-fs/udev-182-r3
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] dev-libs/gobject-introspection-1.30.0-r2
[ 1] sys-apps/kmod-9999
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] dev-util/gtk-doc-1.18-r1
[ 1] sys-apps/hwids-99999999
[ 1] sys-fs/udev-init-scripts-9999

sys-fs/udev-186:
[ 0] sys-fs/udev-186
[ 1] dev-libs/glib-2.30.3
[ 1] dev-libs/gobject-introspection-1.30.0-r2
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] sys-apps/kmod-9999
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] dev-util/intltool-0.50.2
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] dev-util/gtk-doc-1.18-r1
[ 1] sys-devel/automake-1.11.1
[ 1] sys-devel/automake-1.12.1
[ 1] sys-devel/autoconf-2.68
[ 1] sys-devel/libtool-2.4-r1
[ 1] sys-apps/hwids-99999999
[ 1] sys-fs/udev-init-scripts-9999

sys-fs/udev-9999:
[ 0] sys-fs/udev-9999
[ 1] sys-libs/libselinux-2.1.9-r1
[ 1] dev-libs/glib-2.30.3
[ 1] dev-libs/gobject-introspection-1.30.0-r2
[ 1] sys-apps/kmod-9999
[ 1] sys-apps/util-linux-2.20.1-r2
[ 1] dev-util/gperf-3.0.4
[ 1] virtual/pkgconfig-0
[ 1] virtual/os-headers-0
[ 1] dev-util/gtk-doc-1.18-r1
[ 1] app-text/tree-1.6.0-r1
[ 1] dev-vcs/git-1.7.8.6
[ 1] sys-devel/automake-1.11.1
[ 1] sys-devel/automake-1.12.1
[ 1] sys-devel/autoconf-2.68
[ 1] sys-devel/libtool-2.4-r1
[ 1] sys-apps/hwids-99999999
[ 1] sys-fs/udev-init-scripts-9999


--
:wq


rich0 at gentoo

Jul 13, 2012, 6:29 PM

Post #17 of 45 (1240 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 9:21 PM, Olivier Crête <tester [at] gentoo> wrote:
> And on any new embedded platform, one should seriously think about using
> systemd too. It is very lean, replaces most of the giant, unmaintainable
> shellscripts that you find in many devices with smaller compiled code,
> and was designed to be a good fit for embedded devices.

Fair point here - for an embedded device where memory is THAT tight
I'd wonder if ditching the shell might be an attainable goal. C has
to be more memory-efficient.

Rich


caneko at gmail

Jul 13, 2012, 7:32 PM

Post #18 of 45 (1249 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 8:28 PM, Michael Mol <mikemol [at] gmail> wrote:
> On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes <waltdnes [at] waltdnes> wrote:
>> On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
>>> On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes <waltdnes [at] waltdnes> wrote:
>>> > 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's ?too large?? Udev already looks pretty small to me (116k udevd,
>>> 50k libudev, 500k resident memory), and I didn't even try compiling it
>>> with all extra features switched off. If that's too large for an
>>> embedded device, does that device really need (or can handle) anything
>>> more than devtmpfs?
>>
>> What does "equery depgraph" show for udev? Since I don't have udev
>> installed, I can't check it here.

[snip]

> sys-fs/udev-186:
> [ 0] sys-fs/udev-186
> [ 1] dev-libs/glib-2.30.3
> [ 1] dev-libs/gobject-introspection-1.30.0-r2
> [ 1] sys-libs/libselinux-2.1.9-r1
> [ 1] sys-apps/kmod-9999
> [ 1] sys-apps/util-linux-2.20.1-r2
> [ 1] dev-util/gperf-3.0.4
> [ 1] dev-util/intltool-0.50.2
> [ 1] virtual/pkgconfig-0
> [ 1] virtual/os-headers-0
> [ 1] dev-util/gtk-doc-1.18-r1
> [ 1] sys-devel/automake-1.11.1
> [ 1] sys-devel/automake-1.12.1
> [ 1] sys-devel/autoconf-2.68
> [ 1] sys-devel/libtool-2.4-r1
> [ 1] sys-apps/hwids-99999999
> [ 1] sys-fs/udev-init-scripts-9999

A lot of that is optional. The only hard dependencies are:

>=sys-apps/kmod-5
>=sys-apps/util-linux-2.20
dev-util/gperf
>=dev-util/intltool-0.40.0
virtual/pkgconfig
virtual/os-headers

Everything else is optional. I repeat: the idea that udev is somewhat
"bloated" or "fat" is really incorrect.

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


caneko at gmail

Jul 13, 2012, 7:34 PM

Post #19 of 45 (1241 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:
[snip]
> A lot of that is optional. The only hard dependencies are:
>
>>=sys-apps/kmod-5
>>=sys-apps/util-linux-2.20
> dev-util/gperf
>>=dev-util/intltool-0.40.0
> virtual/pkgconfig
> virtual/os-headers
>
> Everything else is optional. I repeat: the idea that udev is somewhat
> "bloated" or "fat" is really incorrect.

Little correction: inherit autotools brings things like automake and
libtool, but then again, almost *every* Gentoo installation has those.

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


williamh at gentoo

Jul 13, 2012, 8:13 PM

Post #20 of 45 (1238 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

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 [at] gentoo> 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


d2racing911 at gmail

Jul 13, 2012, 10:35 PM

Post #21 of 45 (1255 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

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 [at] gentoo>

> 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 [at] gentoo> 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


graham at gmurray

Jul 13, 2012, 11:13 PM

Post #22 of 45 (1245 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

"Walter Dnes" <waltdnes [at] waltdnes> 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 [at] gentoo> 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?


caneko at gmail

Jul 13, 2012, 11:30 PM

Post #23 of 45 (1264 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain <d2racing911 [at] gmail> 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


1i5t5.duncan at cox

Jul 14, 2012, 4:33 AM

Post #24 of 45 (1251 views)
Permalink
Re: udev <-> mdev [In reply to]

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

> "Walter Dnes" <waltdnes [at] waltdnes> 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


peter at stuge

Jul 14, 2012, 2:02 PM

Post #25 of 45 (1256 views)
Permalink
Re: Re: udev <-> mdev [In reply to]

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

First page Previous page 1 2 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.