On Monday 09 February 2009 18:05:20 Andreas Jellinghaus wrote: > picking up only a few lines from your long post: > > > The build system of OpenSC was a mess. > I didn't think of it that badly. but it was me who wrote it, and I still > think it was better than what we had before.
As I don't know what you had before, I can address only what I've seen. > > It did not allow explicit > > dependency enforcement, it had a lot of duplicates and unclean > > autoconf/automake/libtool usage. > > I rewrote the build system and sync it between all of OpenSC > > project for simple maintenance. > > well, the new system is also much more complex due to all the new > options for enabling or disabling something. Yes, but it is required so you can produce different binaries in different configuration at one machine. Without this you ends up with a configuration you did not intend to use. All other good build systems allow explicit enable/disable every dependency. > > 5. The mingw build. > note that I don't have any issue with those using microsoft software as > their operating system also using microsoft software as there compile and > build plattform. the later is available for free (for developing gratis open > source applications at least). not sure how anyone could ever debug complex > problems on windows (e.g. some application or login with using a CSP and > opensc beneth it), but I still guess that a native windows build would make > things easier than a mingw build. as SCB maintainer I was asked for debug > binaries, but didn't manage to properly build them when I was still working > with windows and opensc myself. The binaries are the same, so I don't see there is a huge difference in support. > > 8. OpenCT linux coldplug without usbfs. > > The only requirement for libusb and usbfs in OpenCT was for the > > cold plug process on Linux. > > I wrote a simple replacement using sysfs and dropped the dependency. > > Now OpenCT can be run without usbfs. > > openct with libusb and hal worked fine without usbfs, > as libusb can enumerate files in /dev/bus/usb as well. No... It does not work under mdev. > or you can use the method to create events in /sys/, thanks I was > aware of it, but true: I never implemented it. No events... Just enumerate devices for coldplug. > so you added an implementation for sysfs based cold plugging > and removed libusb, is that correct? I still wonder if supporting > libusb wouldn't be better, maybe even switching completely to > it, so we maybe one day could add mac os X support. but with > your new project that idea is obsolete, and I didn't get around > implementing it for years anyway. First, libusb is still supported but not mandatory, I did not remove anything. Second, on OS X you can always coldplug via the hal/whatever other service they have in core system. > > 9. OpenCT event support. > > OpenCT polled the existence of devices, it also polled the existence > > of card. > > There was a bug in Linux that prevented detecting usb device unplug, > > I've worked with upstream in order to fix it, and it was committed in > > linux-2.6.27.14, linux-2.6.28.3. > > thanks! I wonder if there is any project other than openct depending > this much on a working hotplug. at least with all those bugs and problems > we had over the years with linux kernel, hotplug and udev, I think those > people don't test any complex user space software, and as few other > people found those problems, I think openct is pretty much alone here. > so that was reason at least to me to take the advice and go to the higher > level connection between kernel and openct: hal. I don't think you are correct, most applications used usbfs, and usbfs worked as expected. And this has nothing to do with hal or udev. The kernel *ANY* kernel, should report device removal, it has nothing to do with hotplug. If you have an opened handled to a device that is not available you should be notified directly, via error in poll or signal. If you had an issue the kernel developers will be glad to work without until you reach a solution, exactly as I did. Thanks, Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
