Re: [EMAIL PROTECTED]: src/gas/testsuite ChangeLog gas/i386/divide.d ...]
On Tue, Nov 08, 2005 at 10:10:35AM +1030, Alan Modra wrote: > On i586-pc-gnu, '/' anywhere on the line starts a comment. This is > because the original x86 sysv assembler used '/' to start comments. > In mid 1998, I changed this for the linux version of x86 gas, so that > '/' could be used in expressions as a divide operator. Other flavours > of x86 gas have followed suit since then. Could you please bring that in sync for us as well? Do you know of other issues (in the whole binutils package) where the GNU system differs from the GNU/Linux system? Having a look at the source code I found [gas]/config/te-linux.h, but no [gas]/config/te-gnu.h or similar. E.g. in the Linux file, `LOCAL_LABELS_FB' is defined to `1'. Do we also need that? Regards, Thomas ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [EMAIL PROTECTED]: src/gas/testsuite ChangeLog gas/i386/divide.d ...]
On Tue, Nov 08, 2005 at 10:55:51AM -0500, Thomas Schwinge wrote: > On Tue, Nov 08, 2005 at 10:10:35AM +1030, Alan Modra wrote: > > On i586-pc-gnu, '/' anywhere on the line starts a comment. This is > > because the original x86 sysv assembler used '/' to start comments. > > In mid 1998, I changed this for the linux version of x86 gas, so that > > '/' could be used in expressions as a divide operator. Other flavours > > of x86 gas have followed suit since then. > > Could you please bring that in sync for us as well? I can if you are sure you want it. It will of course break any assembly source you have that happens to use / to start comments anywhere except the first column. > Do you know of other issues (in the whole binutils package) where the GNU > system differs from the GNU/Linux system? You can find differences by comparing entries in the various configure files, particularly gas/configure.tgt and ld/configure.tgt. The most obvious difference is that more linux targets are supported, and linux targets often enable support for related targets like the older AOUT linux target. > Having a look at the source code I found [gas]/config/te-linux.h, but no > [gas]/config/te-gnu.h or similar. > E.g. in the Linux file, `LOCAL_LABELS_FB' is defined to `1'. Do we also > need that? I can add that too. It won't make a difference on most targets. eg. tc-i386.h defines LOCAL_LABELS_FB too. -- Alan Modra IBM OzLabs - Linux Technology Centre ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [EMAIL PROTECTED]: src/gas/testsuite ChangeLog gas/i386/divide.d ...]
> > On i586-pc-gnu, '/' anywhere on the line starts a comment. > > This is because the original x86 sysv assembler used '/' to > > start comments. In mid 1998, I changed this for the linux > > version of x86 gas, so that '/' could be used in expressions as > > a divide operator. Other flavours of x86 gas have followed > > suit since then. > > Could you please bring that in sync for us as well? I can if you are sure you want it. It will of course break any assembly source you have that happens to use / to start comments anywhere except the first column. Please make the change. There is no really good reason why we should differ from GNU/Linux in this regard. And if anything breaks, it will be fixed. > Having a look at the source code I found [gas]/config/te-linux.h, > but no [gas]/config/te-gnu.h or similar. E.g. in the Linux file, > `LOCAL_LABELS_FB' is defined to `1'. Do we also need that? I can add that too. It won't make a difference on most targets. eg. tc-i386.h defines LOCAL_LABELS_FB too. Since it doesn't make a difference, I guess it is just easier to leave it as it is. Thank you. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
The Hurd: what is it?
The lack of direction is annoying. Marcus and I had this long conversation on IRC about the Hurd, Hurd on Mach, Hurd on L4 and Hurd on whatever else, the future, the past and everything inbetween. Right now Hurd on L4 seems to be dead as a stone, more so than Hurd on Mach. And it will require a total redesign, total rewrite of everything, and what not. People are confused where to spend their time and have become more so now that Hurd/L4 might not even be a viable choice. Should time be spent on the currently working Hurd/Mach, should it be spent on the non-existant Hurd/L4, or should it be spent on the Hurd/something-that-doesn't-even-exist-yet? Marcus answer was `that is up to each and one to decide'. This is completely inappropriate from someone who is a co-maintainer. Right now we have two projects that try to achive the same goal while being totally incomaptible with each other, and there is a chance that yet another alternative comes a long that is incompatible with both of the previous efforts. So I'm asking the maintainers (Roland, Thomas) what the heck is the direction of the Hurd is or should be. If it is the Hurd/Mach, then Hurd/L4 should be dropped completely, if it is Hurd/L4, then Hurd/Mach should be dropped compltely, or if it is Hurd/something-that-doesn't-even-exist. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: The Hurd: what is it?
At Wed, 09 Nov 2005 01:43:01 +0100, Alfred M Szmidt wrote: > Right now Hurd on L4 seems to be dead as a stone This is not true (or may have some truth in it, depending on how you define "Hurd on L4"). > And it will require a total redesign, total rewrite of > everything, and what not. This is not true. > People are confused where to spend their time On whose behalf are you speaking? I have not had a single complaint so far. > and have become more so > now that Hurd/L4 might not even be a viable choice. Again, who are you talking about? > Should time be > spent on the currently working Hurd/Mach, should it be spent on the > non-existant Hurd/L4, or should it be spent on the > Hurd/something-that-doesn't-even-exist-yet? > > Marcus answer was `that is up to each and one to decide'. This is > completely inappropriate from someone who is a co-maintainer. Why do you think this is inappropriate? Please cite chapter and verse of the GNU maintainer standard. What do you think is appropriate instead? > Right now we have two projects that try to achive the same goal while > being totally incomaptible with each other, Incompatible in what regard? > and there is a chance that > yet another alternative comes a long that is incompatible with both of > the previous efforts. > > So I'm asking the maintainers (Roland, Thomas) what the heck is the > direction of the Hurd is or should be. If it is the Hurd/Mach, then > Hurd/L4 should be dropped completely, if it is Hurd/L4, then Hurd/Mach > should be dropped compltely, or if it is > Hurd/something-that-doesn't-even-exist. Of course, I don't speak for Roland or Thomas. But as far as I know, the direction of the Hurd has not changed at all. The Hurd-on-L4 efforts are an evaluation of a new design. Until such a design emerges as a viable alternative, there is nothing to decide. You don't explain why such a redesign process is fundamentally incompatible with maintaining the current code base. Consequently, your list of alternatives is narrow and in fact absurd: If one were to follow your advice strictly, no fundamental changes could ever occur in the development of a project. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: The Hurd: what is it?
Marcus, your reply is a kneejerk reaction (I base this on your inablity to understand the meaning of `seems to be dead'). You yourself claimed that Hurd/FOO (FOO != Mach) would require a rewrite, and the only thing left from Hurd/Mach _might_ be libihash. As for whoms behalf I'm speaking for, who has "complained", what the GNU maintainer guide says, all those things are quite irrelevant. If anything, a co-maintainer should know what should be done in the medium to long term. You just reverted to the `hack on what you want' argument with `there is a new design, but there is a old one too' instead of actually answering the question I asked. The facts are that even a person like me who has been around these parts for an awfully long time doesn't even know what the heck to spend time on. It isn't something as trivial as deciding if one should fix rpctrace to be a bit saner, fixing tmpfs, maybe just improving Mach, or deciding how some internal part of exec should be handled. It is about a whole different code base. If the code bases were API compatible, then all would be good, but they aren't and probobly won't be even close to compatible. So the question still remains if one should spend on a code base that works, but might be dumped, or a code base that doesn't work, but might never see the day of light. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: The Hurd: what is it?
> So I'm asking the maintainers (Roland, Thomas) what the heck is > the direction of the Hurd is or should be. If it is the > Hurd/Mach, then Hurd/L4 should be dropped completely, if it is > Hurd/L4, then Hurd/Mach should be dropped compltely, or if it is > Hurd/something-that-doesn't-even-exist. It depends on what the people doing the work think is the most profitable way to spend time. There were people excited about work on L4; if that is no longer true, then what? There were such people, I am/was one of those people. My personal feeling is that L4 is cool, but Mach is simply more feasible to get to a point where it would be useful and decent. Right now it seems that there is a revived interest in Mach (bunch of crazy Spanish speaking people, you know who you are), and a declining interest in L4 which has been redirected at `yet another microkernel'. Thanks Thomas, and nice to see you around! ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: The Hurd: what is it?
El mié, 09-11-2005 a las 02:00 +0100, Marcus Brinkmann escribió: > Of course, I don't speak for Roland or Thomas. But as far as I know, > the direction of the Hurd has not changed at all. The Hurd-on-L4 > efforts are an evaluation of a new design. Until such a design > emerges as a viable alternative, there is nothing to decide. That's the point. Until that evaluation reaches something concrete and _feasible_, I don't see the need to stop Mach/Hurd development, IMHO both projects can work and follow its own way. In fact, I would like to encourage all people to restart working ("working" means coding, but also testing and discussing about design issues) again on GNU Mach/GNU Hurd to make the final effort that it needs to become a production system (the GNU System). Happy Hacking! -- Sergio Lopez [EMAIL PROTECTED] ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: The Hurd: what is it?
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes: > So I'm asking the maintainers (Roland, Thomas) what the heck is the > direction of the Hurd is or should be. If it is the Hurd/Mach, then > Hurd/L4 should be dropped completely, if it is Hurd/L4, then Hurd/Mach > should be dropped compltely, or if it is > Hurd/something-that-doesn't-even-exist. It depends on what the people doing the work think is the most profitable way to spend time. There were people excited about work on L4; if that is no longer true, then what? ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: The Hurd: what is it?
"Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes: > The facts are that even a person like me who has been around these > parts for an awfully long time doesn't even know what the heck to > spend time on. It isn't something as trivial as deciding if one > should fix rpctrace to be a bit saner, fixing tmpfs, maybe just > improving Mach, or deciding how some internal part of exec should be > handled. It is about a whole different code base. If the code bases > were API compatible, then all would be good, but they aren't and > probobly won't be even close to compatible. I think the answer to this question is: we don't know. Work on the L4 codebase is valuable in my opinion; work on the Mach codebase is valuable. They are both valuable in different ways, and I think that there is not a good reason to regard them as so separable. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd