Didn't we just see a different case for usb configuration using .conf
properties?
I'm *really* not a fan of inconsistent property handling -- magic
encoded strings like what is proposed here for portflag seems,... ugly.
Is there a reason why driver/instance number are inadequate to properly
identify a usb device in driver.conf? (usb(4) sheds no light on how usb
properties work.)
It does seem that perhaps an SMF property or something like what
Brussels does for NIC drivers is called for here.
"portflag" as specified looks like a call generator, and a "hack".
Perhaps another approach would be to have a utility that can issue
ioctls against the driver to change its "mode". This can be done once
at start of day (or before first use by other applications) without
requiring other consuming applications to be changed. (Although this
might pose challenges for uses where the device is the serial console
for the system in question.)
-- Garrett
guoqing zhu - Sun Microsystems - Beijing China wrote:
> Andrew Gabriel ??:
>> I'm not a great fan of .conf configuration files.
>>
>> What about using an ioctl to select the mode after opening the device?
> There are some reasons why it does not use ioctl:
> 1. The mode configuration is a electric(physical) characteristics,
> which is transparent to software layer. All existing software APIs
> don't differentiate underlying physical transfer mode(RS232/422/485).
> 2. The mode configuration is dedicated to a special kind device(now is
> only for Edgeport), and it won't become a common property like other
> serial port device modes in software layer.
> 3. It is simple and easy to use, and don't need modify any existing
> software. If we use ioctl, all applications or drivers about USB
> serial perhaps need add a new ioctl and must set correct RS232/422/485
> mode before transfering.
>> Are there any already existing API's in other OS's to allow the
>> application to select the mode it requires? It seems to me like
>> that's the sort of thing an application might well pick out of its
>> own config file (things like MASTER, SLAVE), and use to configure the
>> port appropriately, which it wouldn't be able to do with .conf file
>> configuration.
>>
>> An alternative might be providing additional minor unit number bits
>> and suitable /dev entries (a bit like the /dev/cua no-modem-control
>> devices, or the zs/zsh devices)?
>>
>> What does the API for a RS422/485 port look like? Is it the same as
>> an RS232 port? Does having ldterm and ttcompat autopushed on make sense?
> This mode configuration does not affect ldterm and ttcompat.
> Hope I described it clearly.
>
> Thanks
> Guoqing
>>
>> Artem Kachitchkine wrote:
>>>
>>> I'm sponsoring this fasttrack for Guoqing Zhu. The timer is set for
>>> 05/06/2009.
>>>
>>> My understanding is that even though the initial delivery is for
>>> usbser_edge driver, the proposed interface can be adopted by other
>>> USB serial drivers and new modes added in the future.
>>>
>>> -Artem
>>>
>>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
>>> This information is Copyright 2009 Sun Microsystems
>>> 1. Introduction
>>> 1.1. Project/Component Working Name:
>>> Edgeport USB serial mode configuration
>>> 1.2. Name of Document Author/Supplier:
>>> Author: Guoqing Zhu
>>> 1.3 Date of This Document:
>>> 28 April, 2009
>>> 4. Technical Description
>>> 4.1. Summary
>>>
>>> Support Edgeport USB serial devices RS232/422/485 mode switching mode
>>> via usbser_edge.conf.
>>
>
