Hi Steve,

That's the plan :). However, one aspect of replacing udev with vdev is
making a libudev compatibility library that will let us use exiting
programs and libraries (like Mesa) without having to patch them. This
libudev-compat will probably make use of libsysdev and possibly OS-specific
libraries like libdevq, and for inspiration I was looking at what other OSs
do to address the lack of udev (it seems they have been patching out
libudev support so far, but it also looks like this is getting harder and
harder). If possible, I'd write libudev-compat so that it won't even
depend on vdev--ideally, people could use it with a static /dev if they
wanted, or some other non-Linux device manager like devfs.

-Jude



On Thu, Jan 22, 2015 at 9:54 AM, Steve Litt <slitt@???>
wrote:

> Hi Jude,
>
> I thought you were making vdev to plug replace udev. By the way, when
> it's ready, I have several Epoch and runit experimental setups I'd like
> to use it on.
>
> Thanks,
>
> SteveT
>

> Steve Litt                *  http://www.troubleshooters.com/
> Troubleshooting Training  *  Human Performance

>
>
>
> On Thu, 22 Jan 2015 09:50:11 -0500
> Jude Nelson <judecn@???> wrote:
>
> > I was looking through how FreeBSD handles the lack of udev while still
> > supporting Mesa, and it seems they patched it to use their libdevq
> > [1]. I wonder if there's some overlap with libsysdev here that can
> > be put to use for us...
> >
> > -Jude
> >
> > [1] https://github.com/freebsd/libdevq
> >
> > On Tue, Jan 20, 2015 at 12:01 AM, Jude Nelson <judecn@???>
> > wrote:
> >
> > > Hi Isaac,
> > >
> > > > I was asking about implementation details (something like the
> > > > HACKING document that many projects have, giving an overview of
> > > > how it works internally).
> > >
> > > Good idea; I'll add one.
> > >
> > > > I'm getting the impression that libsysdev won't really make a good
> > > > backend for the udev API; libudev is a much more low-level
> > > > interface, with somewhat different logical division and flow.
> > > > (Abstractly, I'd be happy if it did work. But wasting time for
> > > > the sake of promoting libsysdev isn't going to help replace udev.)
> > >
> > > Interestingly, the libudev API doesn't look that tightly coupled to
> > > the udev implementation to begin with, which is why I consider
> > > libudev-compat to be feasible. Namely, I'm going with the
> > > following implementation strategy:
> > >
> > > udev: library state catch-all
> > > udev_list: this is just a linked list implementation of (key,
> > > value) pairs, which some other methods in libudev happen to return
> > > udev_device: mostly, this is reading data from sysfs and /dev. Not
> > > sure yet about device properties, but I'll figure something out.
> > > Might want to use libsysdev here, and/or recycle parts of vdev's
> > > linux back-end. udev_monitor: don't even bother with netlink.
> > > Just inotify-monitor /dev for changes, so even a static dev will
> > > generate events. udev_enumerate: this is just applying a generic
> > > set of filters on a sysfs directory listing.
> > > udev_queue: don't bother connecting to udev. Just
> > > inotify-monitor /dev again, but do so in the background (i.e. on
> > > library init). udev_hwdb: read udev hwdb files
> > > udev_util: only one string-encoding method; nothing to see here.
> > >
> > > -Jude
> > >
> > >
> > > On Mon, Jan 19, 2015 at 10:55 PM, Isaac Dunham <ibid.ag@???>
> > > wrote:
> > >
> > >> On Mon, Jan 19, 2015 at 08:56:10PM -0500, Jude Nelson wrote:
> > >> > Regarding the architecture, I have a design document here:
> > >> > http://judecnelson.blogspot.com/2015/01/introducing-vdev.html
> > >> > Is this
> > >> what
> > >> > you're looking for? Or did you want a more low-level document
> > >> describing
> > >> > the implementation details?
> > >>
> > >> I was asking about implementation details (something like the
> > >> HACKING document that many projects have, giving an overview of
> > >> how it works internally).
> > >>
> > >> Being mainly acquainted with C, I might not be able to follow it
> > >> myself, but it may well be useful for people who want to
> > >> contribute.
> > >>
> > >> > Regarding whitespace, my style is based on Stroustrup's
> > >> > adaptation of
> > >> K&R.
> > >> > I add whitespace where I do because it helps me read code better
> > >> > and add comments.
> > >>
> > >> Ah.
> > >> I find that the Linux kernel style (also based on K&R) seems most
> > >> clear to me; it seems quite different on the surface.
> > >> (Styles are styles, though. There's always variation.)
> > >>
> > >> > Looking forward to seeing what you do with libsysdev :) I'm
> > >> > seriously considering moving libudev-compat out of vdev
> > >> > entirely, and having it
> > >> use
> > >> > libsysdev as a backend (either way, I don't want it to be
> > >> > coupled to
> > >> vdev).
> > >> >
> > >>
> > >> I'm getting the impression that libsysdev won't really make a good
> > >> backend for the udev API; libudev is a much more low-level
> > >> interface, with somewhat different logical division and flow.
> > >> (Abstractly, I'd be happy if it did work. But wasting time for the
> > >> sake of promoting libsysdev isn't going to help replace udev.)
> > >>
> > >>
> > >> Thanks for the comments!
> > >>
> > >> Isaac Dunham
> > >>
> > >
> > >
>
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>