Re: RFC: integrating inputattach with ldattach (was: gigasetm101d daemon [resent])

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 06, 2008 at 01:23:28PM +0100, Tilman Schmidt wrote:
> Vojtech Pavlik schrieb:
>> On Tue, Feb 05, 2008 at 10:59:09PM -0500, Christoph Hellwig wrote:
>>> On Wed, Feb 06, 2008 at 12:12:05AM +0100, Tilman Schmidt wrote:
>>> > And by the way, what about that
>>> > > kind of tool in
>>> >> one of the input packages to attach input line disciplines
>>> > you mentioned in your mail dated 26.01.2008 20:28? Can you point me
>>> > to a source so that I can make sure ldattach covers its functionality
>>> > too?
>>>
>>> Ok, did a little search in my archives, and it's called inputattach.
>>> It's a package of it's own in most distributions but I can't actually
>>> find an upstream source for it.  I've Cc'ed Vojtech because he wrote
>>> it.
>>
>> I used to maintain it in the linuxconsole.sf.net CVS, now it's
>> maintained by Dmitry Torokhov. Ccing Dmitry - Dmitry, is the development
>> now moved or is still the sf.net repository the master?
>
> Ok, I found a version at
> http://www.kernel.org/pub/linux/kernel/people/dtor/inputattach.c
> which looks reasonably recent (v1.24 2006/02/06) and had a quick
> look.
>
> Apart from the TIOCSETD ioctl which it has in common with ldattach,
> it also contains a large table of device specific data and methods
> for initializing the various input devices which can be driven by
> the N_MOUSE line discipline. In order to merge this into ldattach,
> I would probably extend the <disc> command line argument in order
> to select table-driven pre- and post-TIOCSETD actions and parameter
> presets. For example:
>
> current:  inputattach --mouseman /dev/ttyS0
> -> new:   ldattach INPUT=mouseman /dev/ttyS0
>
> (Defining INPUT as an alias for MOUSE in order to avoid ugly
> combinations like MOUSE=sunkbd. ;-)
>
> I am however somewhat unsure whether such a solution would be
> desirable, or if the requirements of N_MOUSE are so unique as to
> warrant a separate utility. Opinions?
>

I don't have a strong opinion here. How much code will be shared?
Can we keep old name as an alias to the new utility so we dont
break distributions scripts?

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux