| 1 |
Jonathan Callen wrote: |
| 2 |
> On 06/09/2016 10:00 AM, Dale wrote: |
| 3 |
>> waltdnes@××××××××.org wrote: |
| 4 |
>>> On Thu, Jun 09, 2016 at 08:16:57AM -0500, Dale wrote |
| 5 |
>>>> karl@××××××××.se wrote: |
| 6 |
>>>>> Dale: |
| 7 |
>>>>> ... |
| 8 |
>>>>>> Can a system even boot without udev? |
| 9 |
>>>>> Yes, use sys-fs/static-dev (unless you have some special boot |
| 10 |
>>>>> requirements). |
| 11 |
>>>> Well, I was talking about if udev was removed and then a reboot |
| 12 |
>>>> was done. I would think it would boot to a certain point then when |
| 13 |
>>>> whatever started and needed devices to be created in /dev, it would |
| 14 |
>>>> start failing. I suspect this would vary depending on the install |
| 15 |
>>>> as well. |
| 16 |
>>> You need *A* device-manager. You can use udev, eudev, static-dev, |
| 17 |
>>> mdev, whatever, but you need something. Mind you, some software assumes |
| 18 |
>>> or requires udev/eudev. |
| 19 |
>>> |
| 20 |
>> |
| 21 |
>> What I was referring to was if during this switch from udev to eudev, |
| 22 |
>> someone rebooted without any dev manager at all. In other words, emerge |
| 23 |
>> -C udev and then reboot before emerging eudev or some other dev |
| 24 |
>> manager. I suspect that would get interesting pretty quick. |
| 25 |
>> |
| 26 |
>> Dale |
| 27 |
>> |
| 28 |
>> :-) :-) |
| 29 |
>> |
| 30 |
>> |
| 31 |
> Actually, you no longer need a user-space device manager at all, unless |
| 32 |
> you want to be able to access device nodes under /dev as a user that |
| 33 |
> isn't UID=0 or has CAP_DAC_OVERRIDE. The kernel provides a devtmpfs |
| 34 |
> filesystem that will have every single device node that udev used to |
| 35 |
> create (udev no longer even creates the devices -- it just relies on |
| 36 |
> devtmpfs doing so), but most of them will be owned by 0:0 (root:root) |
| 37 |
> with permissions 0600; excepting certain nodes like /dev/null or |
| 38 |
> /dev/zero, which will be owned by 0:0 with permissions 0666. One other |
| 39 |
> thing that udev does that you might rely on is to create symlinks like |
| 40 |
> /dev/disk/by-label/*, which can be used by mount(8) if you specify |
| 41 |
> LABEL=foo in /etc/fstab. The only other things that I'm aware of udev |
| 42 |
> doing is to rename network devices and (possibly) to notify other |
| 43 |
> applications of changes, somehow (but I'm not sure that it actually does |
| 44 |
> that). |
| 45 |
> |
| 46 |
> If you don't actually need any of that (you are working on an embedded |
| 47 |
> system where you only need root anyway, for instance), then you can just |
| 48 |
> use a bare devtmpfs without a device manager changing permissions, |
| 49 |
> adding links, etc. |
| 50 |
> |
| 51 |
|
| 52 |
|
| 53 |
That's interesting to read. I recall reading about the devtmpfs in the |
| 54 |
kernel but thought that was for just the very early stages of booting, |
| 55 |
reading /boot to get the kernel and such things required to start the |
| 56 |
boot process. I figured once it got started, it would eventually get to |
| 57 |
a point and sort of hang up because it couldn't find devices to read to |
| 58 |
keep going. |
| 59 |
|
| 60 |
Interesting. Still don't want to test the theory tho. ;-) |
| 61 |
|
| 62 |
Dale |
| 63 |
|
| 64 |
:-) :-) |
Archives