Am Samstag, 24. März 2007 04:30 schrieb Alan Stern:
Regular files work like that. If a program has a file named foo open
when you do rm foo, the open file reference won't prevent you from
creating a new file named foo in the same directory. There will be no
conflict or confusion between
Hi,
Since last December me and Oliver are trying to
fix a number of problems in usb-serial.c.
Most of them happen when devices are plugged
and unplugged and files are opened and closed
in various orders.
usb-serial.c registers new tty ports by calling
device_register from usb_serial_probe
Hi,
Am Freitag, 23. März 2007 20:36 schrieb John:
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
What about devices that have serial numbers? Wouldn't it at least
be a good idea to make their file usage persistant?
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
What about devices that have serial numbers?
Wouldn't it at least
be a good idea to make their file usage persistant?
I am not sure what you mean as
devices that have
Hi,
Am Freitag, 23. März 2007 20:58 schrieb John:
I am not sure what you mean as
devices that have serial numbers?
USB devices can include a unique serial number allowing even devices
of the same kind to be distinguished.
Thus you would know that exactly the same device has been plugged in.
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
That means the numbers x in ttyUSBx will almost never
be re-used. To me that sounds like something that will
break lots of userspace code.
What about devices
On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
Here two solutions are possible:
1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
reserved until all files are closed.
This is what the current code attempts to do.
But this means that if the same device is re-plugged,
it will be
On Fri, Mar 23, 2007 at 08:42:28PM +0100, Till Harbaum / Lists wrote:
Hi,
Am Freitag, 23. M?rz 2007 20:36 schrieb John:
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
What about devices that have serial numbers?
Those aren't serial numbers in the USB sense.
Consider any FT 232R device, which is assigned
one from the factory
I see. So, aparently, Till wanted to query
for the manufacturer's assigned serial number
and somehow remember which ttyUSBx port
we assigned to it and assign the same number
next
Am Freitag, 23. März 2007 21:18 schrieb David Brownell:
It seems to me that if we cannot guarantee that
the devices are identical, we must make sure they
have different numbers.
That means the numbers x in ttyUSBx will almost never
be re-used. To me that sounds like something that
I say #1 as I implemented it :)
If userspace still has the device node open, then we
need to keep the
number still in use.
OK, if this behavior is by design
(and it is hard to tell what is by design
and what is by accident when you look at a code
without any documentation),
then I will make
On Fri, Mar 23, 2007 at 01:35:44PM -0700, John wrote:
I say #1 as I implemented it :)
If userspace still has the device node open, then we
need to keep the
number still in use.
OK, if this behavior is by design
(and it is hard to tell what is by design
and what is by accident when
--- Greg KH [EMAIL PROTECTED] wrote:
As for applications that foolishly use ttyUSB0 only,
well, they kind of deserve the breakage.
It is pretty trivial to work around that issue
with udev if they want to (and it's recommended
that they fix it that way...)
In this case somebody should
On Fri, Mar 23, 2007 at 07:18:50PM -0700, John wrote:
--- Greg KH [EMAIL PROTECTED] wrote:
As for applications that foolishly use ttyUSB0 only,
well, they kind of deserve the breakage.
It is pretty trivial to work around that issue
with udev if they want to (and it's recommended
On Fri, 23 Mar 2007, Greg KH wrote:
On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
Here two solutions are possible:
1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
reserved until all files are closed.
This is what the current code attempts to do.
But this means that if the
On Fri, Mar 23, 2007 at 11:30:16PM -0400, Alan Stern wrote:
On Fri, 23 Mar 2007, Greg KH wrote:
On Fri, Mar 23, 2007 at 12:36:11PM -0700, John wrote:
Here two solutions are possible:
1. Keep port range (ttyUSB0 and ttyUSB1 in this case)
reserved until all files are closed.
This is
On Fri, 23 Mar 2007, Greg KH wrote:
I don't buy the argument about needing to keep the number in use merely
because the device node is still open. Once the node has been
unregistered it is no longer visible to userspace. Only the existing open
file references can be used, and a new
On Fri, Mar 23, 2007 at 01:30:45PM -0700, John wrote:
Those aren't serial numbers in the USB sense.
Consider any FT 232R device, which is assigned
one from the factory
I see. So, aparently, Till wanted to query
for the manufacturer's assigned serial number
and somehow remember which
18 matches
Mail list logo
