On Thu, Jan 14, 2016 at 11:54 PM, Isaac Dunham <ibid.ag_at_gmail.com> wrote:
> On Thu, Jan 14, 2016 at 12:36:02PM +0100, Laurent Bercot wrote:
> > On 14/01/2016 06:55, Jude Nelson wrote:
> > >I think you're close. The jist of it is that vdev needs to supply a
> > >lot more information than the kernel gives it. In particular, its
> > >helper programs go on to query the properties and status of each
> > >device (this often requires root privileges, i.e. via privileged
> > >ioctl()s), and vdev gathers the information into a (much larger)
> > >event packet and stores it in a directory tree under /dev for
> > >subsequent query by less-privileged programs.
> > I see.
> > I think this is exactly what could be made modular. I've heard
> > people say they were reluctant to using vdev because it's not KISS, and
> > I suspect the ioctl machinery and data gathering is a large part of
> > the complexity. If that part could be pluggable, i.e. if admins could
> > choose a "data gatherer" just complex enough for their needs, I believe
> > it could encourage adoption. In other words, I'm looking at a 3-part
> > program:
> > - the netlink listener
> > - the data gatherer
> > - the event publisher
> > Of course, for libudev to work, you would need the full data gatherer;
> > but if people aren't using libudev programs, they can use a simpler one,
> > closer to what mdev is doing.
> > It's all from a very high point-of-view, and I don't know the details of
> > the code so I have no idea whether it's envisionable for vdev, but that's
> > what I'm thinking off the top of my head.
> I haven't really looked at the vdevd code in a while, but from what
> I recollect...
> The vdev/libudev-compat "solution" is split up as follows:
> -the netlink listener, vdevd
> -several data gatherers, which are invoked according to a set of rules
> for vdevd (analogous to mdev.conf)
> -helper scripts to create extra links and so on, run via the same rules
> -I don't recall exactly how the event publishing is done, but IIRC,
> there's a daemon watching the directory where the helpers write out the
> data, and then distributing it as described
-libudev-compat is libudev, patched to read events that are published
> as described
> -IIRC, there's some helper that will (also? instead?) maintain a list of
> devices more like the way udev does, so you don't *need* libudev-compat.
Yup--all the requisite device state is maintained under /dev/metadata. The
libudev-compat event helper behaves just like any other vdev/mdev-style
script--when invoked, it reads /dev/metadata for a given device, sets up
the appropriate files in /run/udev, and generates, writes, and hard-links
the event-file (which libudev-compat clients detect and consume).
Libudev-compat is totally unnecessary if device-aware programs and scripts
can get away with reading and watching the contents of /dev/metadata.
Received on Sat Jan 16 2016 - 13:25:03 UTC