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
>>
>
>