Re: [coldsync-hackers] New snapshot: 2.2.0

["Mike Durian" <durian@boogie.com>]

On Wed, 08 Aug 2001 12:05:21 EDT, Andrew Arensburger <arensb+CShackers@ooblick.com> wrote:
>
>	Bugger. Have you tried it with
>		protocol: net;
>in the listen{} block?

I just tried it.  Still no luck.

>	At any rate, when I get a chance to add non-NetBSD USB support,
>what'll happen is that I'll try to abstract the BSD-specific system calls
>from the USB-specific handling. That is, I assume that with all USB
>implementations, you'll need to get the manufacturer and device info, find
>the proper endpoint, etc., so that'll stay in libpconn/PConnection_usb.c .
>However, it's only under *BSD that you'll use
>	ioctl(int fd, USB_GET_DEVICEINFO, struct usb_device_info *udi);
>so that'll have to be moved to PConnection_usb_bsd.c or some such.

That makes sense.  It'll be easier to abstract it properly after
viewing a few other implementations.

>	Where we disagreed earlier, I think, was on the level of
>abstraction. If I read you correctly, you had modified PConnection_usb.c
>in such a way as to present the same API for USB under BSD, and USB under
>Linux. I didn't think it was a good thing to try to shoehorn a serial
>interface and a USB interface to work the same way.

That was what I did.  Though from my perspective, it wasn't so much
that I was trying to shoehorn serial and USB together.  I just didn't
realize that the Linux implementation truly was serial.  I thought
it was USB that had a serial flavor to it.

I saw one file that did Visor USB for BSD and another file that did
m50x USB for Linux and thought it would be nice to allow either
palm protocol to be used over either USB implementation.

What you say about making usb an alias for serial under Linux makes
sense.

I'm going to think aloud here for a moment.  From a polymorphic
view point there are two ways to handle the palm protocols vs.
physical interfaces (including different USB implementations)
combinations.  You can start with the palm protocol and select
an appropriate physical interface polymorphically or start with
the physical interface and make a polymorphic call to the
appropriate palm protocol.

My patch, which bounced, did it the first way.  I used compile
time #ifdefs on the OS to select an appropriate physical interface
for a palm protocol.  Your current code uses the other approach.
It starts with a physical interface and uses a switch statement
to select the correct palm protocol.  I can't really think of
a reason why one approach would be better than the other.

However, I do think there can be improvement on using the #ifdef
or switch() statements.  The rest of the code uses function pointers
to hide the polymorphism.  I think that's the correct approach for
this too.  That way you don't have to worry about using a switch
statement to unwind the different protocol stacks at all the exit
points.  Instead you just call (*palm_proto)->unwind().

I'm not sure what you do when you have OS specific code that won't
compile under other OSes (BSD USB vs. Tru64 USB).  Just tackle
it via autoconfig?

mike
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.