Re: [EMAIL PROTECTED]: src/gas/testsuite ChangeLog gas/i386/divide.d ...]

2005-11-08 Thread Thomas Schwinge
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 ...]

2005-11-08 Thread Alan Modra
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 ...]

2005-11-08 Thread Alfred M\. Szmidt
   > > 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?

2005-11-08 Thread Alfred M\. Szmidt
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?

2005-11-08 Thread Marcus Brinkmann
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?

2005-11-08 Thread Alfred M\. Szmidt
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?

2005-11-08 Thread Alfred M\. Szmidt
   > 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?

2005-11-08 Thread Sergio Lopez
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?

2005-11-08 Thread Thomas Bushnell BSG
"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?

2005-11-08 Thread Thomas Bushnell BSG
"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