On Wed, 6 May 2009 14:28:58 +0000 (UTC) "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx> wrote: > New ports may be accepted in past branches to a limited extent, but we > don't want newer branches and trunk to regress relative to them; at > least, if adding a port to an old branch I'd say you need also to have a > trunk version, with all the sysdeps files updated for all the post-2.5 > changes in the libc versions of those files, to commit to trunk at the > same time, and to keep that version up to date in future, even if if > won't work for lack of TLS. I also strongly recommend working on TLS > support and an NPTL port. Mm, tracking trunk as well as having code in the 2.5 branch seems like a sensible thing to do, I assume I wouldn't have to worry about the other branches between 2.5 and trunk? TLS is something that is on the cards, but as fair as I'm aware, isn't going to pursued until the toolchain patches have found their way upstream. As fair as I'm aware NPTL requires TLS? So not much can be done about that at this stage. (Other than preliminary work obviously). Also, in order to get 2.5 to work all the notls patch[0] from debian has been used, as I mentioned. Is this something that could potentially be commited into this branch? If it hasn't already been. > One thing to consider for a new port is symbol versions; if you are not > bound by backwards compatibility to old binaries, you can set the > minimum symbol version (DEFAULT line in shlib-versions) to the version > for which you add support on trunk (GLIBC_2.11, supposing this is not in > before 2.10 branches) and so avoid some compatibility code in the > libraries. How would this work if there was a port put into the 2.5 branch? I assume you'd have to have GLIBC_2.5 in trunk also? Or could you just forget about that and use GLIBC_2.11? In that light do you think it's really worth pushing code into the 2.5 branch or just worry about trunk? (obviously with it not working due to the lack of TLS). > EGLIBC follows the same copyright assignment requirements as FSF glibc, > so all significant contributors to the port must have copyright > assignments for it (naming GLIBC / GNU C Library, not EGLIBC), and > employer assignments/disclaimers as needed, on file at the FSF before we > can consider the port. This is something I need to do, are there any documents anywhere explaining what needs to be done for this? > Subject to that, EGLIBC can certainly take ports > not in the FSF glibc ports collection, although that would mean you need > to undertake to update sysdeps files in EGLIBC to account for changes to > the libc version after I merge in the libc changes from FSF glibc at > irregular intervals (as opposed to after the changes are committed to > FSF glibc, which would be the case for ports in the FSF ports > collection). Going into EGLIBC first and then to the FSF glibc once everything is finished and ready seems like a less painful, more sensible route to me, so I'm happy with the need to do that. > Although I don't think there is a requirement that the other toolchain > components have their ports present upstream before a port goes into > EGLIBC, getting them upstream is still a very good idea to facilitate > testing; a conventional order would be to get binutils upstream first > (since a binutils port can be tested using just the binutils > testsuites), then GCC (which may be tested on simulators if available > for a bare-metal target, for which the libc (newlib?) port is likely to > be simpler than glibc), then EGLIBC once the tools are available to > build the EGLIBC port. If support has been added to a free simulator > (e.g. QEMU or the GDB simulator), then that would be contributed at any > convenient point; likewise a GDB port. So I encourage working on those > other submissions (and the prerequisite copyright assignments) if not > already done. They may be more critical if you wish at some point to > add the port to the FSF ports collection. The binutils and GCC ports (and possibly GDB) are already making their way upstream (currently stuck in the legal department I believe), and there is a uclibc port already. A QEMU port has been attempted in the past by myself and others, so this is something that may reappear in the future. > At least, you need to point to where the ports of other components can > be found. Likewise, there should be a public psABI document available > at a known location. Do you have an official ELF e_machine value for > the port (obtained from registry@xxxxxxx; nowadays CC the > http://groups.google.com/group/generic-abi group)? That's something > that it's also a good idea to finalise before submitting toolchain ports > upstream (actually, it's a good idea to get at the very first stages of > starting a port). Currently there isn't a public psABI document anywhere, although I'm told there is an unofficial one available which I'm currently trying to get hold of, I shall look further into this. In light of what you said about the e_machine number, I've just discovered that the value currently being used is an unofficial one, so this is going to need to be sorted out too, but is obviously very much in Atmels hands since it will affect them a great deal. Regards, Bradley Smith [0] http://files.brad-smith.co.uk/local-notls.diff.txt -- Bradley Smith brad@xxxxxxxxxxxxxxxx Debian GNU/Linux Developer bradsmith@xxxxxxxxxx GPG: 0xC718D347 D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347
Attachment:
signature.asc
Description: PGP signature