On Mon, 2008-03-24 at 17:00 +0300, Bakulin Ilya wrote:
> On Sat, 22 Mar 2008 14:12:47 +0200
> Markus Niemisto <[EMAIL PROTECTED]> wrote:
>
Hi Markus, glad you're here !
I'm only going to touch on hal at the moment, because I don't know
sync-engine that well.
> > Hi list,
> >
> > I was trying to get synce to work with my WM6 PDA and FreeBSD 7 the other
> > day.
> > There was a few things I had to do. With the attached patches I am able to
> > sync and access my device using palm/uppc-kmod driver from FreeBSD ports. I
> > also used old opensync 0.22 framework. Of course I had to disable the
> > Advanged network functionality on my PDA.
>
> Very glad to see you as FreeBSD & SynCE user! I have some questions to you:
> 1. What application are you syncing with?
> 2. What PDA do you have? I tried to use uppc-kmod driver and get this error:
> ==============
> ucom0: <HTC USB Serial for Wizard, class 0/0, rev 2.00/0.00, addr 2> on uhub1
> ucom0: failed to set configuration, err=STALLED
> device_attach: ucom0 attach returned 6
> ==============
> , while uipaq driver works fine. Of course, FDI rule remains the same because
> upper-level driver (ucom) remains the same.
>
> > The first patch, hal-freebsd.patch, addresses a few FreeBSD specific hal
> > DCCM
> > issues. First, linux/if.h header doesn't exist on other platforms. I think
> > net/if.h should work on Linux too, but I ifdef'd it just in case. Second
> > issues was that usb-rndis-ng rule in 10-synce.fdi created some conflicts so
> > I
> > removed it. I also tried to make the FreeBSD ucom rule more general.
>
When I wrote hal-dccm I copied a lot from odccm. It looks like if.h
isn't needed at all, so I'll remove it.
> What exactly conflicts were caused?
>
Yes, what were the conflicts ? I'm not sure if anyone is still using the
-ng driver, but I'd rather not remove the rule entirely.
I obviously can't say much about the ucom rule, Bakulin does this new
version work for you as well ?
> >Then I made some adjustments for hal-synce-legacy script. There were few
> >other
> > things I noticed: device file handling did not work at all on FreeBSD,
> > FreeBSD ppp doesn't support linkname, and last, at least on my computer,
> > HAL
> > 0.5.11rc2 doesn't set environmental variable HALD_ACTION. HAL also searches
> > the scripts only from $prefix/libexec so I adjusted the Makefile
> > accordingly.
>
> I used hal-0.5.10 (of course not from ports) and HALD_ACTION exists there...
> Will try with 0.11 soon.
> I also removed all linkname stuff, and used /dev/cuaU${HAL_FREEBSD_UNIT}.
>
Looking through the patch:-
The hal helper dir ie. libexecdir, varies across a lot of platforms. I
would rather not change it to /usr/libexec in svn. My Makefile skills
aren't great, if someone can come up with a test that would be best, or
I'll try and write a configure option.
HAL_PROP_LINUX_DEVICE_FILE is not obviously not very cross platform,
does freebsd have HAL_PROP_SERIAL_DEVICE ?
Does the linkname option cause ppp to fail ? Its quite handy for
multiple devices.
Has something replaced HALD_ACTION in 0.5.11 ? It would seem odd that
such an important item was removed entirely.
> > The third issue the second patch fixes is something I had quite hard time
> > to
> > figure out. It seems that rapi contexts are created and stored into TLS so
> > they are per thread. So when the rapi context is created in main thread in
> > kernel.py and used later in another thread in synchandler.py, librapi
> > method
> > rapi_context_current() returns new, uninitialized context, that results in
> > sync-engine crash. I fixed this by creating and using a new rapi context in
> > SyncHandler.run() method. This makes the thing work.
>
> Great! Now SynCE doesn't coredump while syncing to Google-calendar. (instead,
> Google calendar doesn't work, don't know why yet) :)))
>
> > At least hal-synce-legacy and 10-synce.fdi need some work to be platform
> > independet, but now the thing works on FreeBSD.
> Yes, but now HAL also invokes synce-scripts when plugging in USB2COM bridge
> (PL2303-based in my case. I actively work with ARM- and MIPS-based
> development
> boards and use these bridges because my laptop doesn't have ordinary COM
> ports).
> This is not good. I think that we should hack HAL itself to include
> information
> about lower-level driver (uipaq, uppc) in ucom-based device node... Or add
> info
> about more PDA vendors to 10-synce.fdi :-)
>
Adding vendors in 10-synce.fdi is an option, but could quickly get out
of control. If you could both post the device information using
hal-device we may be able to see a better option.
Mark
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SynCE-Devel mailing list
SynCE-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synce-devel
