[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
anyway)?
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':
KERNEL=="ttyS0"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '/devices/pnp0/00:08':
KERNELS=="00:08"
SUBSYSTEMS=="pnp"
DRIVERS=="serial"
ATTRS{id}=="PNP0501"
looking at parent device '/devices/pnp0':
KERNELS=="pnp0"
SUBSYSTEMS==""
DRIVERS==""
*** udev output for /dev/ttyS3:
(ridouan@buntu) udevadm info -a -n /dev/ttyS3
looking at device '/devices/platform/serial8250/tty/ttyS3':
KERNEL=="ttyS3"
SUBSYSTEM=="tty"
DRIVER==""
looking at parent device '/devices/platform/serial8250':
KERNELS=="serial8250"
SUBSYSTEMS=="platform"
DRIVERS=="serial8250"
ATTRS{modalias}=="platform:serial8250"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Other related posts:
