| 1 |
On Mon, 22 Sep 2014 16:14:11 +0000 (UTC) |
| 2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
| 3 |
|
| 4 |
> |
| 5 |
> Again, bottom line, report kernel breakage of userspace, the same kernel |
| 6 |
> cycle that breakage happens if at all possible, which means testing an |
| 7 |
> early enough kernel rc (rc3 is good) |
| 8 |
> |
| 9 |
|
| 10 |
That certainly is good advice but unfortunately, even if I had the |
| 11 |
desire, I do not have the wherewithal to follow kernel development |
| 12 |
too closely. But the next time I see breakage with a new kernel |
| 13 |
I will fire off a quick message to LKML about it. |
| 14 |
|
| 15 |
Also, my example of the changes in USB device nodes is not the only |
| 16 |
recent occurrence of /dev tree modifications. The kernel folks also |
| 17 |
removed the static /dev/rtc, or real-time clock device node. In place |
| 18 |
there is now /dev/rtc1, /dev/rtc2, etc., and the intention is to |
| 19 |
dynamically allocate these nodes with udev. This change broke my |
| 20 |
use space but it was easy to fix. |
| 21 |
|
| 22 |
But does this represent a creep toward having the kernel depend on |
| 23 |
the user-space udev (or its equivalents)? Because I don't closely |
| 24 |
follow kernel development I cannot say for certain, but it sure seems |
| 25 |
that way. |
| 26 |
|
| 27 |
Let's face it. The static device tree is "old" Unix and is way |
| 28 |
out of the current fashion. The "old" way is to know your hardware |
| 29 |
and manually configure accordingly. The "new" way is to have the system |
| 30 |
determine your hardware and do the configuration for you (based |
| 31 |
on a distributed database of zillions of entries, possibilities, |
| 32 |
and permutations). |
Archives