Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

2018-01-15 8:39 GMT-03:00 Laurent Bercot: > > The change is obviously incompatible with mdevd-0.0.1.0. It appears to > work for me, but please test it - especially Olivier who was missing > events with the old coldplug. If no problems are found, I'll cut the > 0.1.0.0 release. Worked for me too.

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

And to answer your question, about what could cause such a burst of events, this time I have an easy answer: mdevd-coldplug ! Yes, I forgot to mention this. The kernel-generated events seem to be significantly heavier than the mdev-style synthetic ones. The DEVPATH is the full path without

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

On Mon, 15 Jan 2018 11:39:19 + "Laurent Bercot" wrote: > The change is obviously incompatible with mdevd-0.0.1.0. It appears > to work for me, but please test it - especially Olivier who was > missing events with the old coldplug. If no problems are found, I'll >

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

2018-01-12 23:10 GMT-03:00 Laurent Bercot: > > There are modules for which a /sys/class entry, and an appropriate > major/minor pair for mdevd to create the device node, only appear when > the module is loaded, and there's no prior uevent file to trigger > loading the module: the one I've tested

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

It might be worth to look at what systemd [1] and eudev [2] do here. When 'udevadm trigger --type=devices --action=add' is performed after the udev daemon starts executing, it looks like what happens is basically this: Thanks a lot for studying this. That's what I was going to do, but I

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

2018-01-09 21:35 GMT-03:00 Laurent Bercot: > > What it looks like is the kernel not assigning a major and a minor > to the device before you manually trigger the "add". I suspect it's > just that the relevant module is not loaded, but why would that be > different from any other hardware managing

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

On Wed, 10 Jan 2018 00:35:33 + "Laurent Bercot" wrote: > Question that may help: > - does your /sys/devices/pci:00/:00:01.0/:01:00.1 > directory contain a "dev" file: before you manually trigger the add? > afterwards? Nope, afraid not; neither before

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Thing is, before writing to that uevent, there was nothing of the sort in /sys/dev. What it looks like is the kernel not assigning a major and a minor to the device before you manually trigger the "add". I suspect it's just that the relevant module is not loaded, but why would that be

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

On Mon, Jan 08, 2018 at 07:31:17PM +, Laurent Bercot wrote: > > #!/usr/bin/execlineb -P > > pipeline { find /sys -type f -name uevent -print0 } > > forstdin -0 -p f importas -u f f redirfd -w 1 $f echo add > The problem with your script is that it's getting a lot of > duplicates, since

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

However, somewhat recently I believe I heard (read) you say on IRC that the recommended way was actually the other way around, so I switched to start netlinkd first, and then run coldplug. Well, it's really up to you. The thing is, if you coldplug first then listen to the netlink, you have a

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Le 16/11/2017 à 12:31, Laurent Bercot a écrit : I fully understand that this list is focused on good programming practice and libudev is considered something disgusting in that respect. My question was triggered by the frustration, probably shared by many, of not being able to replace Udev by

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

I fully understand that this list is focused on good programming practice and libudev is considered something disgusting in that respect. My question was triggered by the frustration, probably shared by many, of not being able to replace Udev by Mdev or Mdevd, only because Xorg autoconfig

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Le 16/11/2017 à 10:25, Casper Ti. Vector a écrit : On Wed, Nov 15, 2017 at 02:53:21PM +, Laurent Bercot wrote: Is it really the only place in Xorg that depends on libudev? I'd think it would be much, much more entangled with libudev than this. Unfortunately, just as noted by Guillermo,

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Le 15/11/2017 à 19:27, Laurent Bercot a écrit : "Applications should not access sysfs" doesn't mean there should be only one version of the intermediate library. There's already Systemd-Udev and Eudev versions, at least. For the case of Xorg, it just means sysfs access should not be

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

2017-11-15 14:11 GMT-03:00 Didier Kryn: > > I don't know what evdev is (I guess some virtual device) and what's its > place in the big Xorg picture, but I think some of you guys know it. Any > usefull link? X11 comes in pieces; there is the server, normally installed as /usr/bin/X and / or

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

"Applications should not access sysfs" doesn't mean there should be only one version of the intermediate library. There's already Systemd-Udev and Eudev versions, at least. For the case of Xorg, it just means sysfs access should not be hard-coded in the source of Xorg, but there should be

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Le 15/11/2017 à 15:53, Laurent Bercot a écrit : Linus has said, multiple times, that sysfs wasn't supposed to be a stable interface, so applications should just not access sysfs. "Applications should not access sysfs" doesn't mean there should be only one version of the intermediate

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Le 12/11/2017 à 20:24, Laurent Bercot a écrit : Will there be a plan to add something roughly isomorphic to libudev? Not in the short or medium term. The problem of libudev, and this is shared by everything from freedesktop.org as well as systemd, is that its design and structure cannot be

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Will there be a plan to add something roughly isomorphic to libudev? Not in the short or medium term. The problem of libudev, and this is shared by everything from freedesktop.org as well as systemd, is that its design and structure cannot be achieved without a monolithic implementation, and

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Will there be a plan to add something roughly isomorphic to libudev? On Mon, Oct 23, 2017 at 08:02:33AM +, Laurent Bercot wrote: > mdevd is an uevent manager reading a sequence of uevents and handling > them without forking, that understands the full /etc/mdev.conf format. -- My current

[announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

Hello, About two years ago, there was some talk on the Busybox mailing-list about the need for a version of "mdev" that would not use a separate process for every uevent (as a hotplug manager does) but that would act as a daemon, able to handle a series of uevents - typically read from the