On Wed, 6 Feb 2008 10:20:01 -0500, "Dmitry Torokhov" <dmitry.torokhov@xxxxxxxxx> said: > On Wed, Feb 06, 2008 at 01:23:28PM +0100, Tilman Schmidt wrote: > > 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? Basically, just the actual ioctl(TIOCSETD) and the final daemon() call. The line setup (bitrate, parity, etc.) is similar too, but gets fed the parameter data from different sources. (Device table in your case, command line in mine.) > Can we keep old name as an alias to the new utility so we dont > break distributions scripts? It can be done of course. I would have to switch do different argument parsing depending on the name the program is called by. Doable, and not particularly difficult at that. But I'm still not sure whether it's really a good idea to throw these two programs into one. It does complicate things. Regards, Tilman -- Tilman Schmidt tilman@xxxxxxx - 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
