[argyllcms] Re: Running dispcal stops usb card reader

  • From: Ridouan Agarad <ridouan@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 16 Feb 2012 04:04:43 +0100

On 16-02-2012 02:24, Graeme Gill wrote:
Do they create a lock file in /var/lock/LCK..tty<XX> ?

Eh, file locking per /var/lock/... would be a 'convention' and advisory only. It might well be an application doesn't play 'nice' and create the appropriate lock file... So, it would be somewhat unreliable. The advantage of this kind of advisory locking is that you wouldn't need superuser privileges (as opposed to finding out which handles a process has open, via /proc). On the other hand, on linux probing for which files are open by a process via the /proc/<pid>/fd directory is guaranteed, since it's a reflection of the datastructures as kept by the OS for that specific process.

Well, looking a bit closer at the documentation, I don't have argyllcms running 
(on Linux) and
can't check, I guess using the '-c' parameter for e.g. dispcal would already 
allow one to achieve
this, wouldn't it?
No, because the -c list is populated by looking for all the serial ports,
which is what is causing the problem we are discussing... :-)

Yeah, I was bit too focused on the serial port part, for some reason I was thinking that the argument for -c would match the serial port, but there's also USB to consider ofcourse...

Isn't /proc/devices maybe usable as an 'automatic' filter (if the file is 
available, that is) to
filter out devices for which no driver is currently loaded (and thus not usable 
I looking into that, but /proc/devices only lists the drivers, so it will
match all ports handled by that driver, whether they are real or not.

Looking at /dev again on more recent Linux systems, perhaps
there really isn't a problem with listing all the ports that match
(ie. I see only 4 on my system, one of which is real).

Graeme Gill.

Just did some experimenting on an embedded linux and a VMware version to see how (actual) serial ports were handled. As usual, everything is done differently depending on version, etc, etc... *deep sigh*.

On both machines (embedded = 2.6.37-x64, VMware = ubuntu 10.10 2.6.35), I only had ports ttyS0 through ttyS3. A quick peek at /dev/MAKEDEV (superseded by udev on recent linux releases) showed there might be even a ttyS4 and ttyS5, but I guess that's pretty exceptional (unless someone has a serial port addonboard, but that would be outside the scope...). The VMware machine allowed me to vary the number of 'physical' serial ports available and see the effect it had on the OS.

So, the results are:

The script-approach (dmesg | grep ttyS) reported the correct number of ports available, on both machines. Problem with this is that if someone did 'dmesg -c' it wouldn't work anymore, not really that elegant (aside from using a script-approach in a compiled program).

It appears that nowadays the creation and removal of serial ports ttyS* entries (whether they're physical or virtual USB ports) is handled by udev. It's accessible programmatically and allows you to enumerate the devices to determine all kind of (fun) info. On the embedded machine I had to use the command 'udevinfo -a -n /dev/ttyS0' and on Ubuntu I had to use 'udevadm info -a -n /dev/ttyS0' to get info on /dev/ttyS0. So basically, looking at the output for diffent ports, it *appears* to be the case that if e.g. /dev/ttyS0 is an actual serial port, udevinfo/udevadm reports the driver as 'serial' with attribute ID='PNP0501' and if the ttyS port is not available, e.g. /dev/ttyS3 in my case, the driver is reported as 'serial8250' without an 'ID' attribute. Whether this is 100% always the case I can't say, given my rather limited sampling (2 machines)... Googling however did give me some hope it might be so on the majority of linux installations.

Another quick way might be to access this information directly via the file system. It appears that that for e.g. ttyS0 the information can be found in /sys/class/tty/ttyS0/*, where the symlink 'driver' points to the driver for that port (either serial or serial8250 in my case). The directories for the specific port contains all kinds of info (e.g. a "resources" file with the allocated system resources).

*** udev output for /dev/ttyS0:
(ridouan@buntu) udevadm info -a -n /dev/ttyS0
 looking at device '/devices/pnp0/00:08/tty/ttyS0':

  looking at parent device '/devices/pnp0/00:08':

  looking at parent device '/devices/pnp0':

*** udev output for /dev/ttyS3:
(ridouan@buntu) udevadm info -a -n /dev/ttyS3
  looking at device '/devices/platform/serial8250/tty/ttyS3':

  looking at parent device '/devices/platform/serial8250':

  looking at parent device '/devices/platform':

Other related posts: