On Thursday 04 February 2010 17:51:36 CeDeROM wrote: > On Thu, Feb 4, 2010 at 9:31 PM, Mike Frysinger 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
remind me again how this isnt exactly the same thing that i'm talking about (bumping SONAME when the ABI changes), and how this is "better" than Linux where the ABI of the C library never changes. > 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). none of this applies to SONAME management (library ABI) in random 3rd party packages like urjtag. > > 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? :-) Rutger already put together a call and what we have today is the result of his immense work. i dont think people are going to review the API for their needs and suggest generic interfaces here. they're going to use what works for them. > 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... way beyond what is important to me. honestly, the only thing i'm really concerned with is the smooth functioning wrt Blackfin processors because that's what i use urjtag for. i know urjtag supports other cables/devices, but i dont use them ... -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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 UrJTAG-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/urjtag-development
