Hello Mike! On Thu, Feb 4, 2010 at 9:31 PM, Mike Frysinger <[email protected]> wrote: > are you sure ? first of all, FreeBSD user<->kernel is the exact opposite of > Linux -- they have evertyhing intertwined so that they can break ABI as they > like. g'luck taking a FreeBSD-4 binary and running it with FreeBSD-7. > however, any Linux userspace binary should continue to work because the > syscall ABI has been set in stone. > > plus, the default FreeBSD library policy is terrible. just look at the soname > conventions used in libtool. that's why for the Gentoo/FreeBSD port, we > actually change the convention to use Linux SONAME policies. we get sane > upgrade paths.
Well there is no problem with running release 6 or 7 binaries on 8 release as I do this for example with OpenOffice - apropriate loaders are provided with the system. Indeed there are some little issues that from release a library name changes version ie. libm.so.4 -> libm.so.5 but that can be easily fixed. There are also tools to upgrade or install packages that automaticaly resolves conflicts (ie. portupgrade, portinstall). But the most important thing for me is that the directory structure, configuration files, parse, etc are the same - this standard allows me working on my problems not my system and if I say "do this on your fbsd system" I can be almost sure that this will work just as on my system :-) There are many different Linux distros, each one of them use its own tools and configuration scheme, packaging system etc - its hard to tell wether a program from one distro will work on the other distro. I understand that new features requires some changes in Linux and I really liked for instance the ramfs infrastructure presented recently to the kernel, as I did some porting stuff recently at work, but these features being added often breaks compatibility (ie. alsa drivers for ich-sound). > i'm not talking about bumping it every time or taking the approach loosely. i > am talking about the first release or two being "developer previews" without > any stable guarantee. > > we also dont have any symbol versioning support in here, so until that's done, > i dont think talking about a stable ABI is appropriate. Fully agree. Maybe it is a good time to start? :-) There are a lot of experienced users on the list dealing with many different sorts of hardware, so maybe we can gather some kind of requests or ideas for such a generic jtag library interface? :-) My first idea is to support JTAG and SWD (and probably others) with the same function set, so the bus could be easily initialized/deinitialized for devices using both of them - ie Rlink cable can do JTAG and SWD, Rlink is installed on STM32Primer 1 and 2 while Primer1 use JTAG and Primer2 use SWD - it would be nice to simply select cable, mode and use the same function set to do the programming... Maybe some function should set system default for bitswapping, maybe this should be done with a separate function on a loaded buffer with data, maybe this sould be done just when transferring buffer data to the cable driver... Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
