Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 17 Jul 2018, 19:17
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
populating /dev from /sys
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 4 of 4 [54 Posts]   Goto page: Previous 1, 2, 3, 4
Author Message
technosaurus


Joined: 18 May 2008
Posts: 4822
Location: Kingwood, TX

PostPosted: Thu 22 Jan 2015, 16:21    Post subject:  

Ibidem wrote:
FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.

There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.

I may be wrong, but I think those events are handled internally -- it needs help with hot plug events such as plugging in a wireless mouse after X is running.

_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson

PostPosted: Thu 22 Jan 2015, 21:20    Post subject:  

technosaurus wrote:
Ibidem wrote:
FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.

There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.

I may be wrong, but I think those events are handled internally -- it needs help with hot plug events such as plugging in a wireless mouse after X is running.


Might I ask what "those events" refers to in your comment?

The inotify bit is one possible way of listening for hotplug events.
Hotplugging a GPU/input device means a new device appears in /dev/dri or /dev/input, or an old one disappears; I'm figuring that we can check for that by means of an inotify watch.

As far as I can tell after skimming xorg-xserver source, there are several possible "config" backends for the X server that seem to be responsible for hotplugging; the main code for these is in config/<backend>.c, and I can't really tell exactly where they hook up or how X listens for hotplug events.
I do know config/config.c calls the setup and teardown needed for "the current config backend", and include/hotplug.h declares the functions in config/config.c.
You can build the server with any one of several config backends, or with none; wscons, udev, and HAL are the currently available backends.
Each of these will try to figure out an appropriate driver for each device, then load that driver specifying the device.
When evdev is the driver loaded, it will check whether an input device is "virtual" or not (meaning roughly "is it a pointer or keyboard, or is it something else?") so it knows whether to refuse to proceed.
The way evdev checks this is by finding the corresponding sysfs path and checking if it contains the string "LNXSYSTEM"--if evdev finds that string, it bails out.
Generating this path is currently done by libudev.

mesa somehow-or-other ends up with an fd for a DRI device (without using udev), then uses udev (or some sysfs fallback code that you must manually enable) to get the corresponding PCI ids and parses those PCI ids to determine the mesa driver.

...Ah, that's it: the udev backend installs a wakeup handler (named wakeup_handler(), of course) with RegisterBlockAndWakeupHandlers(). But I'm not sure exactly how all that works; it's a bit above my pay grade Wink. Perhaps udev sends a signal, perhaps it's something along the lines of select() on a socket...
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4822
Location: Kingwood, TX

PostPosted: Fri 23 Jan 2015, 05:29    Post subject:  

I was referring to button/key presses

A netlink socket like udev uses will catch hotplug events ... example here:
https://www.kernel.org/doc/pending/hotplug.txt

_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson

PostPosted: Sat 24 Jan 2015, 02:06    Post subject:  

technosaurus wrote:
I was referring to button/key presses

A netlink socket like udev uses will catch hotplug events ... example here:
https://www.kernel.org/doc/pending/hotplug.txt


I'm more wondering how to make X11 catch hotplugging (esp. devices appearing)...without depending on a particular hotplug helper.
In particular, my hope is to work with mdev, vdev, udev, hotplug2, or even static /dev.
If someone runs mknod /dev/input/mouse1 c 4 64 from an xterm, it would be nice if X could go "Ah, there's a new...mouse! Let's load *that* driver!"
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4822
Location: Kingwood, TX

PostPosted: Sat 24 Jan 2015, 04:45    Post subject:  

I know it may sound ridiculous but, the X server could be used as the hotplug handler by just monitoring the netlink hotplug socket in the same loop as the unix domain (or tcp) socket ... or even use select(). For _most_ users the X server is, for all intents and purposes, essentially a daemon anyhow. In fact as part of my nanosaurus experiment, Xvesa and jwm were forked off of /init as if they were a daemon.
_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Sat 24 Jan 2015, 04:52    Post subject:  

Currently, the only two places to catch kernel events are from using netlink, like udev does, or from using /sbin/hotplug, The hotplug interface is more limited as it only responds to 'add' or 'remove' events. The systemd guys want to replace netlink with a d-bus implementation in the kernel -kdbus. If you don't want to depend on anything, then you need to re-implement any of the above functionalities -but why re-do what is already there. Especially if it means having to patch and maintain patches to any program wishing to use those services. netlink is already in the kernel, so why not just use it and be happy?
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4822
Location: Kingwood, TX

PostPosted: Tue 24 Nov 2015, 12:39    Post subject:  

amigo wrote:
-but why re-do what is already there. Especially if it means having to patch and maintain patches to any program wishing to use those services. netlink is already in the kernel, so why not just use it and be happy?
netlink requires a continuously running daemon ... I for one don't continuously add/remove devices enough to warrant an extra running process. The problem with the old hotplug scripts is that they mandated posix sh compliance and thus made a bunch of calls to external binaries. Builtin read and substring manipulation can replace most external calls to the extent that the user won't even see a time lapse. With a couple of minor modifications to busybox (marking more things like mknod as nofork/noexec) you get near udev performance without the overhead of a udevd.
_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
amigo

Joined: 02 Apr 2007
Posts: 2641

PostPosted: Tue 24 Nov 2015, 13:25    Post subject:  

Hmmm, I'm probably the last person on the planet who stopped using hotplug! -back in the day when udev was debated just like systemd is these days. In between, we had the same for hald and the *-Kit's...

I'm all for a better /sbin/hotplug, although making it depend on busybox doesn't sound nice either. I worked on some stuff for hotplug using bash3. There are the two other disadvantages of hotplug -seriality and the fact that it passes less environment to the handler(which might provide extra options/functionality).
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4822
Location: Kingwood, TX

PostPosted: Tue 24 Nov 2015, 14:45    Post subject:  

amigo wrote:
I'm all for a better /sbin/hotplug, although making it depend on busybox doesn't sound nice either. I worked on some stuff for hotplug using bash3. There are the two other disadvantages of hotplug -seriality and the fact that it passes less environment to the handler(which might provide extra options/functionality).
I'm not saying that we should, just that busybox could perform at speeds close to that of udevd ... any modern shell will work, but having things like mknod (and other required external binaries) as a builtin would improve performance.
_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 4 of 4 [54 Posts]   Goto page: Previous 1, 2, 3, 4
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2139s ][ Queries: 12 (0.0617s) ][ GZIP on ]