| 1 |
On Tue, 19 Jan 2016 16:06:26 +0000 (UTC), James wrote: |
| 2 |
|
| 3 |
> > > Let's be clear: static-dev is NOT a workaround. It is a full proper |
| 4 |
> > > solution for the case when a dynamic device node solution is not |
| 5 |
> > > desired. |
| 6 |
> |
| 7 |
> Well, I can think of embedded (linux) systems, a lock-down server and |
| 8 |
> machine(s) loaded up with (NFV) Network Function Virtuals, as prime |
| 9 |
> examples where a static dev is very useful; albeit a management pain if |
| 10 |
> one is not careful. This is a very interesting topic for me. |
| 11 |
|
| 12 |
Whatever your setup, you need something to manage your entries in /dev. |
| 13 |
That's why there is a dependency on the dev-manager/virtual. What you use |
| 14 |
is up to you: udev, eudev, systemd, devfsd, busybox or doing it manually, |
| 15 |
is up to you. That's why any of those satisfy the dev-manager virtual. |
| 16 |
That's why Alan said that static-dev is not a work around, it is a valid |
| 17 |
choice that sets up a limited number of static nodes that you then manage |
| 18 |
yourself. You are the dev-manager. |
| 19 |
|
| 20 |
|
| 21 |
-- |
| 22 |
Neil Bothwick |
| 23 |
|
| 24 |
Don't judge a book by its movie. |
Archives