On Saturday 10 March 2007, Jiri Kosina wrote:
>On Sat, 10 Mar 2007, Gene Heskett wrote:
>> >I think there is alternative for you that can be done completely in
>> >userland, without seeding mess into the kernel driver - do you think
>> > it would be feasible that you create a trivial and small library,
>> > that
>>
>> I'm not up to writing a library. 15 years ago maybe, before the wet
>> ram started to fade (I'm 72 now), I was pretty good with the 8 bit
>> machines and wrote code & built boards in 1980 for an 1802 machine
>> that was used till the later 90's, and repeated that in 1989 which we
>> used till 2002, but linux is a whole new concept even if I have been
>> running it since rh5.1 days. Are you aware of something that might
>> serve as a starting framework to be hacked into doing this?
>
>This is really failry trivial thing to do. Just cook up a fake wrapper
>ioctl() library, something like this:
Ok, saved this out, along with the instructs. Looks easy enough except
for the reference source for the 'magic' numbers.
Where, as in what /usr/include/file.h, will I find a list of the 'magic'
numbers, or what file would I also #include in order to be able to write
these in human readable formats? Would /usr/include/bits/termios.h be
suitable? I did a recursive grep for BAUD, and thats about all that fell
out that had even a semi-interesting name. linux/serio.h appears to have
the PARITY stuffs, but not the BAUD stuff. It seems there should be a
better choice, but its not obvious.
>== ioctl.c ==
>#define _GNU_SOURCE
>#include <dlfcn.h>
>
>long ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
>{
> long (*orig_ioctl)(unsigned int, unsigned int, unsigned long) =
> dlsym(RTLD_NEXT, "ioctl");
>
> if (cmd == /* put here the evil ioctl number the app is calling
> */) return 0;
> else
> return orig_ioctl(fd, cmd, arg);
>}
>==
>
>Then compile this like
>
> gcc -shared -ldl ioctl.c -o ioctl.so
>
>and then just execute your strange_application by
>
> LD_PRELOAD=ioctl.so /path/to/broken/strange_application
>
>Every ioctl() the application issues will then first pass through your
>wrapper, where you can catch all the broken ioctl(), and let the correct
>one pass through glibc to kernel on its usual way.
>
I hope that will work. The running daemon is of course called upsd, but
even the starter gizmo is a compiled utility of some sort that one puts a
copy of as 'S99bulldog' in each /etc/rc`runlevel`.d directory where one
wants it to run.
>I am still however pretty far from being convinced that this will make
>your application work. But as I absolutely don't know what your
>application is expecting to obtain from serial port and how does this
>compare to what it is getting from usb hiddev, it's just wild guesses.
The serial ports data, which comes out of /dev/ttyUSB0 via the pl2303
cable, looks to be more verbose than the hiddev0 data, containing lots of
semi-colons. So its entirely possible this won't work but it will be an
interesting experience for me to see if it can be done.
This comm path, in either case, is bidirectional, the driver can control
the ups from its gui. Is this? It looks as if it should be though.
Thanks Jiri, I appreciate the help.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
bit bucket overflow
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
