Re: [coldsync-hackers] Re: USB m50x under FreeBSD

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

[This message bounced too, again due to the message size limit on the
list.]

On Sat, Jul 28, 2001 at 10:50:24PM -0000, "Mike Durian" <durian@boogie.com> wrote:
> On Sat, 28 Jul 2001 16:09:44 EDT, Andrew Arensburger <arensb+CShackers@ooblick.com> wrote:
> >	Having said this, I'm now thinking that adding a new
> >"usb_m50x" listen type was the wrong approach. Better to make that a
> >modifier of the listen block. That is, the listen{} block in
> >.coldsyncrc should take a "protocol:" option. Thus, under Linux, if
> >you have a plain Visor, you'd use
> 
> But then you have to know the protocol type.

	Well, yes. Just as you currently need to know the protocol
type to know whether to use "serial" or "usb_m50x". My point is that
the "hardware" (serial, usb) protocols and the "software" (SLP+PADP,
netsync) protocols are nearly orthogonal.
	For all I know, it might even be desirable to use SLP+PADP
over TCP. It might be useful if ColdSync is on the server end of a PPP
connection that the Palm has dialed in to. Or some other unforeseen
situation.

> If you go with the
> command line flag, then you can just set up two rules in /etc/usbd.conf,
> one with a vendor ID of 0x082d that runs coldsync with the appropriate
> command line arg to do the visor protocol and and with a vendor ID
> of 0x0830 that does the m50x protocol.  That way the user doesn't
> have to pay attention to these things.

	Using the newly-added "-P <protocol>" option, you'd set up one
entry in /etc/usbd.conf that runs
		coldsync -t usb -P default
(or just 'coldsync -t usb') and another that runs
		coldsync -t usb -P m50x

> Though the best solution would be if the protocol could be detected
> at run time.  That way you just specify how you're connected,
> serial or usb and coldsync takes care of the rest.  I think you
> can use the USB calls to determine the vendor ID and make this
> distinction at runtime under FreeBSD, but I don't know about Linux
> given the serial/USB kernel conversion you described.

	This might be nice, but it seems like chrome. It seems that
this feature would be most useful in two situations: a) new users, and
b) situations where the protocol stack changes from moment to moment.
For (a), an FAQ or README seems like a more appropriate solution. For
(b), I'm proceeding under the assumption that the protocol stack is
tied to the cradle, not the Palm model; if this assumption proves
incorrect, then autoconfiguration might become necessary.

> >	Unfortunately, it looks as if you forgot to include the
> >"libpconn/usb_bsd.c" and "libpconn/usb_linux.c" files
> 
> They were in there, just diffed against /dev/null which I thought
> would automatically create them.

	Oops! You're right. My bad. I was looking in the wrong place.

> Despite your leaning towards a different solution, I'll resend
> my diffs anyways in the hope someone can help me understand what's
> going on with this code.

	I've trimmed the patch from this reply, so as not to run
against the same 40000-char limit.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
	     Programming is an art form that fights back.
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.