Moreover, vdev will support the option of simply generating the device
files for the system's current hardware configuration and promptly
exiting. You won't have to leave it running, and if your hardware
configuration changes, you can simply re-run it and it will add/remove the
requisite device nodes.
-Jude
On Sat, Jan 17, 2015 at 1:37 PM, Gravis <ring3k@???> wrote:
> karl, what's with the hostility? vdev is by no means required and
> nothing depends on it, so nobody is being forced to even install it.
> also, since it is based on FUSE, it won't actually add/remove static
> device files, so when the program exits, it will go back to your
> static device files. you can set rules in the vdev config file so
> that you can make devices behave as you wish. vdev is still in
> development, so no behavior is set in stone and can updated for new
> situations as they are discovered/reported.
>
> On Sat, Jan 17, 2015 at 12:49 PM, <karl@???> wrote:
> > t.j.duchene@???:
> >> From: Hendrik Boom
> >> Sent: Wednesday, December 31, 2014 8:44 AM
> >>
> >> > Never mind the mechanisms for now.
> >> > May I ask what all this complexity is supposed to accomplish?
> >
> > (please don't top post)
> >
> >> The reasons for a dynamic device manger were simple:
> >>
> >> a) Actually makes sure that the device really exists, and is
> >> connected rather than having a static /dev entry that is
> >> essentially worthless.
> >
> > Isn't that a thing for the local administrator to decide upon ?
> > Don't force people.
> >
> > I've been bitten by not having an /dev entry even though the
> > device was there. Udev done me disservice more than once.
> >
> >> b) A dynamic manager provides a consistent way for naming device
> >> nodes, rather than having administrators create nodes willy-nilly.
> >
> > If I "willy-nilly" create devices then I don't want some daemon to
> > change that, and I don't appreciate the need to relearn things just
> > because 90% of the others found out a new way of doing things.
> >
> >> c) Provides a persistent API for managing the devices programmically,
> >> so that you can add device capabilities to your user programs in a
> >> consistent fashion.
> >
> > There is an api for "managing" devices: open/close/read/write/ioctl/...,
> > mount, umount, etc.
> >
> > But I suspect you are aiming for something else.
> >
> > From the little I know about libudev, there is the ability to map
> > major/minor to /dev/-name. Something else ?
> >
> >> That's more than enough reason to not go back to the old way of
> >> doing things, although it should be noted that you can create a
> >> system library to manage static nodes in a similar fashion.
> >
> > Some people are not "going back", they just don't embrace every
> > new thing; they just stay on firm ground.
> >
> >> Most of the reasoning behind the most used managers is to allow
> >> "hotswapping" without manually mounting
> >> I don't have a problem with this, as long as the security
> >> implications are considered in advance.
> >
> > That ortogonal to having *dev managing /dev, and if desktop users
> > wants their usb-disks to be automatically mounted, let them, but
> > don't force me.
> >
> > If I unplug the one and only disk on the system (/dev/sda), no
> > amount of udev trickery will help my system from crasching, since
> > the kernel will assign it a new major/minor number - the
> > current one is locked by the root file system.
> > It does not matter at all whatever name it has in /dev, since it
> > won't be the same device in the kernels view, and all commands you
> > try to use to remedy the situation with will segfault unless they
> > are already in memory.
> >
> > You could do that with the old /dev/hda, because the kernel assigned
> > the disk the same major/minor number each and every time you attaced
> > the drive in the same place (same cable, same connector, same
> > strappings).
> >
> > What you name things in /dev, is just a convenience, what really
> > matters is what major/minor number you come up with in the end.
> >
> > So, what's all the fuss whith what name there is in /dev/, let
> > each and every user *be able* to decide for themselves.
> >
> > Regards,
> > /Karl Hammar
> >
> > -----------------------------------------------------------------------
> > Aspö Data
> > Lilla Aspö 148
> > S-742 94 Östhammar
> > Sweden
> > +46 173 140 57
> >
> >
> > _______________________________________________
> > Dng mailing list
> > Dng@???
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
::
Re: [Dng] Purpose of all this compl…
