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.
I actually already have that trick used to log all events, so I can
tell you that since I booted I've had 640 events processed.
Just ran mdevd-coldplug again, and now I have 1172 events logged, so
that's 532 events generated by mdevd-coldplug just now.
In my log I have basically the output of "d
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
sy
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
> cut the 0.1.0.0 release.
T
OK, I did this, I compared what I got by reading every
/sys/class/*/*/uevent and /sys/bus/*/devices/*/uevent file (like
mdevd-coldplug does for /sys/dev/*/*/uevent) with what I got by
writing 'add' to them (like udevadm trigger does) and then using
'udevadm monitor --kernel --property' to watch
2018-01-13 12:40 GMT-03:00 Guillermo:
>
> 2018-01-12 23:10 GMT-03:00 Laurent Bercot:
>>
>> Anyway, I will change to what udev does; but this is annoying because
>> it requires a rearchitecture, so it will take some time.
>>
>> With the mdev -s model, it was possible to just read from sysfs,
>> sy
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 i
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 would
On Thu, 11 Jan 2018 23:29:45 -0300
Guillermo wrote:
> #/bin/execlineb -P
> elglob sysclass /sys/class/*/*/uevent
> elglob sysbus /sys/bus/*/devices/*/uevent
> forx f { $sysclass $sysbus }
> importas -u ueventfile f
> redirfd -w 1 $ueventfile
> echo add
Just tried this, and it worked fine; All my
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
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 nor after. What happens i
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
differe
First off, about the buffer issue, I'm not sure why but I couldn't
reproduce it. :/ Rebooted a few times, with the default buffer, and
mdevd-netlink never complained.
I still have the old messages in my logs, it happened every single
reboot, and not once this time don't know. Maybe I'll try ag
By that I mean, currently if I don't do anything else, some things
aren't processed. For instance, my audio card isn't there, neither are
a few input devices, such as my (usb) mouse.
I can't reproduce the problem on my system: mdevd-coldplug detects
all the USB devices. But it's a small syste
On Mon, 08 Jan 2018 19:31:17 +
"Laurent Bercot" wrote:
> >But, it seems to me that when you're talking about this you expect
> >one to have two different instances of mdevd, one for netlinkd &
> >another one
> >for coldplug. That's not how I made things however: mdevd is a
> >longrun and I si
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 multipl
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 wi
Hey there :)
So I've been using this (instead of your old uevent handler & busybox's
mdev) for a little while now, works great; Thanks!
I do have a few questions though. Originally what I had done was to
start mdevd, run mdevd-coldplug (referred to as coldplug thereafter),
and then start mdevd-ne
Excuse me for insisting so long and off-topic. For my excuse let me
say my only will was to use mdevd *and* Xorg. I'm not fond of politics
more than you. Let's put an end to this thread.
It's ok. It's not off-topic: I wrote mdevd, so I should expect those
discussions.
Casper brought a goo
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
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 ha
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, li
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, libudev is also, in more
complicated ways, needed b
Le 16/11/2017 à 03:01, Guillermo a écrit :
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, normal
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 hard-coded
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 /us
"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 so
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 librar
The only fragment in xf86-input-evdev that requires libudev is
(from src/evdev.c, with some changes in whitespaces):
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.
Because if it's that single piece of code,
After googling `LNXSYSTEM', I found this to be seemingly doable using
regular Unix filesystem mechanisms on sysfs. But sysfs seems to be
controlled by the systemd people [1], so this is more of a political
issue than of a technical issue. (Or perhaps this is just a part of the
grand conspiracy, i
The only fragment in xf86-input-evdev that requires libudev is
(from src/evdev.c, with some changes in whitespaces):
> ...
> #include
> ...
>
> static BOOL
> EvdevDeviceIsVirtual(const char* devicenode)
> {
> struct udev *udev = NULL;
> struct udev_device *device = NULL;
> struct stat
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 ach
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 ar
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 Open
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 net
35 matches
Mail list logo
