Subject: Re: Embedded NetBSD?
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/28/2001 00:09:31
On Mon, 29 Oct 2001, Greg A. Woods wrote:
> [ On Monday, October 29, 2001 at 16:54:43 (-0500), Andrew Cagney wrote: ]
> > Subject: Re: Embedded NetBSD?
> > Greg A. Woods wrote:
> > >
> > > Why? Especially when it means everyone else using NetBSD must
> > > effectively jump through unreasonable hoops!
I missed the start of this thread; what "hoops" are we talking about?
Are we talking about the name of a file whose value really doesn't matter
(say a file used for compiling)? Or are we changing the name of an
often-used tool (like ls)? Or something inbetween?
It's silly not to change something in NetBSD's sources that has low
NetBSD-impact yet will make life easier for cygwin or another cross-os
> > > NetBSD is a far more suitable environment for hosting its own
> > > development as an embedded system than any other platform could ever
> > > possibly be!
So? No one has said that it wouldn't be best to use NetBSD as the
developement platform. What people have said is that there are a number of
places where folks want to use NetBSD on a target, but can't use NetBSD as
the build system. The question is, do we want to help these folks out or
> > Sorry, but this is funny. Time passes the words change but the issue
> > remains the same. This time the buzword is embedded. Last time it was
> > portability.
> Yeah, well, what do you expect? NetBSD is, by definition, the best
> host platform for its own development since it is a proper self-hosting
> > It is wrong to assume that someone porting NetBSD to a new platorm will
> > have access to an existing [native] NetBSD environment.
> Now that NetBSD (almost) supports full cross-builds, you're almost
> certainly wrong on that point, and more importantly you're definitely
> wrong if the alternate platform is running on hardware that would itself
> support native NetBSD.
No, you're wrong. The original statement is correct. But for a reason you
aren't listening to.
You are missing the case of folks who are *administratively* not permitted
to use NetBSD. It's not that they have hardware we don't support, it's
that they are in a place whose policy doesn't support NetBSD.
I thankfully haven't worked in such a place, but they do exist. And I
agree with you that it would probably be much saner for them to use
NetBSD. But that doesn't change the fact that they exist.
So what do we do? Say we don't care about them?
> > It is
> > reasonable, however, to assume that they will have access to a UNIX like
> > environment such as AIX, MINIX, Linux, CYGWIN, OpenBSD and even, gasp,
> > NetBSD.
> The assumption should be that the filesystems on which the source files
> will be stored are similar enough to the native host environment that no
> changes be required in the source tree hierarchy and naming. It would
> seem that necessarily rules out use of antiquated systems, even when
> they've been coerced too look somewhat unix-like, such as Cygwin, U/Win,