[patch] to gdb: portability fix: <sys/file.h>

Michael Sokolov msokolov@ivan.Harhan.ORG
Tue Feb 6 20:03:00 GMT 2001


DJ Delorie <dj@redhat.com> wrote:

> The problem is that there is a *separate* repository inside Cygnus
> (now Red Hat), which is *the* "cygnus tree" (now the "Red Hat tree" I
> guess).

I know this very well, and *that* is the tree I really want to be working on if
I could, but I can't because it isn't free and I'm not affiliated with Red Hat.

I'm not working with FSF/GNU. I will never work with FSF/GNU because the GNU's
Not UNIX project is by definition working against UNIX, and UNIX is my personal
OS of choice. (It is also one of the official OSes of the IFCTF and IESTF, but
in this case it doesn't matter as much as UNIX being my personal OS of choice
because my involvement with the embedded development toolchain is mostly
personal, I'm not really representing the IFCTF or IESTF official position
here.)

The only remote connection between me and any GNU projects is that I like the
Cygnus toolchain for embedded development, and it has some GNU-based components
in it, and generally follows the GNU coding standards even in the non-GNU
modules. While I don't appreciate Cygnus' decision to follow the GNU coding
standards as opposed to, say, the Berkeley ones, I really really like the
Cygnus toolchain for embedded development, and I'm in no position to rewrite
the whole thing. I compromise by having a separate partition on my machine (and
in my life) for embedded development, and I tolerate some GNU-ness there,
exactly as much as I need in order to work with the Cygnus toolchain.

Now if all I wanted was to *use* the Cygnus toolchain, i.e., passively use a
given static version of it, I would just pick up some Cygnus release from
somewhere and use it. However, I want to actively work on a tree that many
other qualified developers are working on. There are two such tree, the Red Hat
internal one, which has all the bright Red Hat engineers working on it, and the
public one on sources.redhat.com, which has all the FSF/GNU folks working on it
(I politically disagree with FSF/GNU, but there are still very good people
working on FSF/GNU projects). The former is definitely better, but it's non-
free and I'm not affiliated with Red Hat, so it isn't an option and I have to
settle for the latter.

> The repository on sources.redhat.com is *not* the "cygnus
> tree".  It is the FSF's respository.

sources.redhat.com:/cvs/src is not FSF's, it has some FSF projects in it, but
it also has non-FSF Cygnus modules like Newlib, Insight, Cygwin, etc.

> Then perhaps your platform should choose a different maintainer?  One
> who has a desire to learn how to integrate their platform's needs with
> the needs of the project?

Do you mean that someone else should maintain the Berkeley UNIX code or the
support for it in the Cygnus toolchain and the GNU parts of it? But either way,
that is extremely unlikely. In the former case, I volunteered to bring 4.3BSD
back from the ashes in 1998 after no one else did in 10 years, since UC
Berkeley dropped it in 1988. In the latter case, I'm sure you know that 4.3BSD
does not use any GNU tools natively. If someone uses 4.3BSD in this millennium,
he/she certainly does so very conscientiously for political or religious
reasons, and all people using 4.3BSD today (whom I know as I lead the dev team
and we have a mailing list) feel the same way about FSF/GNU as I do. I
volunteered to maintain 4.3BSD host support in the Cygnus toolchain and its GNU
parts only because I like the Cygnus toolchain for embedded development. The
chances of someone else both using 4.3BSD and doing some embedded development
using the Cygnus toolchain are vanishingly small.

Oh, I do care very much about the needs of Cygnus toolchain overall (I assume
that's what you meant by "the project"), as I use it for embedded development,
and I want a good embedded development toolchain, not a crappy one.

> If you want your platform supported in the official
> sources, you'll have to cooperate and compromise, just like everyone
> else.

And I do that. My little patch does the same thing I've seen in a ton of places
elsewhere in the tree, and I don't see how it tries to make gdb conform to the
V7/4.3BSD way of doing things. I do cooperate and compromise. (I'm always
disappointed when people use memcpy/memmove instead of bcopy, for example, I
want it exactly the other way around, but I don't bitch about it publicly on
these lists.)

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)


More information about the Gdb-patches mailing list