Re: Removing ARCNET stuffs
mlel...@serpens.de (Michael van Elst) writes: > jo...@britannica.bec.de (Joerg Sonnenberger) writes: > >>On Tue, Jun 02, 2015 at 11:47:01AM -0700, Dennis Ferguson wrote: >>> Asking for ARCNET support in the absence of hardware to test on, >>> however, is really asking for something quite different. Since you >>> can't make more than small, mechanical changes to anything and expect >>> it to work without testing (and I'm not even sure about the small, >>> mechanical changes) what is being asked instead is that nothing be >>> done that requires changes to the ARCNET code on the disk right >>> now, nor the framework it relies on to operate, while making it >>> someone else's problem to figure out how to deal with that constraint. >>> This isn't fair, and I don't think it has any possibility of working. > >>Amen. > > There are several NetBSD developers that own ARCNET hardware and > that could help out. You could also get new cards, at "industry" prices. This tricky "could!" It almost never answers the question, whether it is some hypothetical possibility or readiness to act. -- HE CE3OH...
Re: Removing ARCNET stuffs
Oops, s/epilogue/prologue/ in below On 8 June 2015 at 15:15, David Holland wrote: > On Mon, Jun 08, 2015 at 07:18:24PM +0200, Anders Magnusson wrote: > > David Holland skrev den 2015-06-08 19:06: > > >On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote: > > > >> printfing from the back of the front end is definitely "totally wrong > > > >> in other ways that need to be rectified first" :( > > > > Hm, I may be missing something, but what is wrong? > > > > Where should you print it out otherwise? > > > > > >I would say the debug information ought to be attached to the > > >representation nodes it describes as it moves through the backend; > > >otherwise it's easily upset by fairly simple transformations. > > > > It's simpler than that :-) > > > > Debug info for all data declarations etc are printed out when found, > > so are the declarations themselves. No reason to keep them. > > ...except perhaps for, say, removing unused static variables :-) > > > Debug info for code follows the code itself. This is necessary, since > > the debug info must follow the reference to a place in the code stream, > > otherwise the debug info might refer to a label that is optimized away > > which is not acceptable by the assembler :-) > > Ok, never mind then; was responding to what was posted rather than > what actually exists... > > -- > David A. Holland > dholl...@netbsd.org
Re: Removing ARCNET stuffs
On Mon, Jun 08, 2015 at 07:18:24PM +0200, Anders Magnusson wrote: > David Holland skrev den 2015-06-08 19:06: > >On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote: > > >> printfing from the back of the front end is definitely "totally wrong > > >> in other ways that need to be rectified first" :( > > > Hm, I may be missing something, but what is wrong? > > > Where should you print it out otherwise? > > > >I would say the debug information ought to be attached to the > >representation nodes it describes as it moves through the backend; > >otherwise it's easily upset by fairly simple transformations. > > It's simpler than that :-) > > Debug info for all data declarations etc are printed out when found, > so are the declarations themselves. No reason to keep them. ...except perhaps for, say, removing unused static variables :-) > Debug info for code follows the code itself. This is necessary, since > the debug info must follow the reference to a place in the code stream, > otherwise the debug info might refer to a label that is optimized away > which is not acceptable by the assembler :-) Ok, never mind then; was responding to what was posted rather than what actually exists... -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On 8 June 2015 at 13:18, Anders Magnusson wrote:
> David Holland skrev den 2015-06-08 19:06:
>>
>> On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote:
>> >> printfing from the back of the front end is definitely "totally wrong
>> >> in other ways that need to be rectified first" :(
>> > Hm, I may be missing something, but what is wrong?
>> > Where should you print it out otherwise?
>>
>> I would say the debug information ought to be attached to the
>> representation nodes it describes as it moves through the backend;
>> otherwise it's easily upset by fairly simple transformations.
>>
> It's simpler than that :-)
>
> Debug info for all data declarations etc are printed out when found,
> so are the declarations themselves. No reason to keep them.
Traditional stabs, with their very limited capacity to describe whats
going on don't exactly help (there are extensions), but they aren't
really the problem.
As you note, data values are printed by stabs.c:stabs_newsym() at the
start of a block. For instance:
case AUTO:
cprint(0, "\t.stabs \"%s:%s\",%d,0," CONFMT ",%d\n",
sname, ostr, N_LSYM, (CONSZ)suesize, BIT2BYTE(s->soffset));
break;
case REGISTER:
cprint(0, "\t.stabs \"%s:r%s\",%d,0,%d,%d\n",
sname, ostr, N_RSYM, 1, s->soffset);
break;
it might be mostly correct at .O0 when on a statement boundary, but
not when there's an optimizer. For instance:
- stack values never get written back to the stack
- multi-register values are never in contiguous registers
(which is why debuggers invariably print wrong values). The compiler
needs to describe where values are, for failing that, describe that
the value was lost.
> Debug info for code follows the code itself. This is necessary, since
> the debug info must follow the reference to a place in the code stream,
> otherwise the debug info might refer to a label that is optimized away
> which is not acceptable by the assembler :-)
In stabs.c:stabs_line, there's what I'm going to call a "gem":
void
stabs_line(int line)
{
if (inftn == 0)
return; /* ignore */
Part of debugger folk law is to set a breakpoint on a function the
debugger needs to do something like:
- find foo
- find foo's first stabn
- set a breakpoint on the stabn, and then cross fingers and hope that
the compiler hasn't sneezed
the above code, which suppresses line-number information in the
epilogue, explains why.
Even without optimization shooting us in the foot, a program that
stops (crashes) inside the epilogue (or initialization of a block, or
mid way through a statement) has wrong information(1) - the stack
isn't fully formed for instance (I suspect there was also folk law
saying debuggers should surreptitiously single-step to the next stabn
when they find the program stopped between two lines).
Andrew
(1) it may also have trouble unwinding, but that is another story
Re: Removing ARCNET stuffs
Andrew Cagney skrev den 2015-06-08 19:18: I'm clearly out-of-date regarding SSA, its nice to be corrected. No problem :-) On 8 June 2015 at 09:06, Anders Magnusson wrote: Andrew Cagney skrev den 2015-06-01 20:41: I do not understand why either of those choices need to be taken. Pcc has a reasonable intermediate representation, which in the optimizer is converted to SSA form, hammered on, and converted back. This is done while retaining the intermediate representation, which is no problem. I'm being fast and loose. My reading of the code was that debug info was being generated by the back of the front end (very roughly "gimplify" in this diagram of GCC https://gcc.gnu.org/projects/tree-ssa/#ssa). It was pretty much hard wired printfs, and explained to me why "-g -O" wasn't supported. printf's are only used for data (which is spit out directly), not code. All code is dealt with function-wise, otherwise things like the register allocator would not work. Unless, I guess, what you're talking about is throwing away the existing backend entirely and writing a new SSA-based one, in which case I'd gently suggest that this is a large project :-) Exactly :-( What is wrong with the existing backend? As you state, the representation gets taken into and then out of SSA. Why bother; at least for the converting to-ssa side? The rest of the compiler works on the (quite simple) internal representation which is very easy to deal with. The SSA conversion code is only a minor part of the compiler backend (and somewhat complex) so it is better to keep it separate. Also, going directly to SSA in pass1 would require all different language frontends to have knowledge about it, which is unneccessary. Basic steps in the backend are: - Delete redundant jumps (simplifies SSA) - SSA conversion, (optim), remove phi nodes - Assign instructions - Allocate registers - Emit code Turning off optimizations basically just skips the first two steps :-) -- Ragge
Re: Removing ARCNET stuffs
I'm clearly out-of-date regarding SSA, its nice to be corrected. On 8 June 2015 at 09:06, Anders Magnusson wrote: > Andrew Cagney skrev den 2015-06-01 20:41: >> > I do not understand why either of those choices need to be taken. > Pcc has a reasonable intermediate representation, which in the optimizer > is converted to SSA form, hammered on, and converted back. This is > done while retaining the intermediate representation, which is no problem. >> >> I'm being fast and loose. My reading of the code was that debug info >> was being generated by the back of the front end (very roughly >> "gimplify" in this diagram of GCC >> https://gcc.gnu.org/projects/tree-ssa/#ssa). It was pretty much hard >> wired printfs, and explained to me why "-g -O" wasn't supported. > > printf's are only used for data (which is spit out directly), not code. > All code is dealt with function-wise, otherwise things like the register > allocator would not work. > >>> Unless, I guess, what you're talking about is throwing away the >>> existing backend entirely and writing a new SSA-based one, in which >>> case I'd gently suggest that this is a large project :-) >> >> Exactly :-( >> > What is wrong with the existing backend? As you state, the representation gets taken into and then out of SSA. Why bother; at least for the converting to-ssa side? Andrew
Re: Removing ARCNET stuffs
David Holland skrev den 2015-06-08 19:06: On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote: >> printfing from the back of the front end is definitely "totally wrong >> in other ways that need to be rectified first" :( > Hm, I may be missing something, but what is wrong? > Where should you print it out otherwise? I would say the debug information ought to be attached to the representation nodes it describes as it moves through the backend; otherwise it's easily upset by fairly simple transformations. It's simpler than that :-) Debug info for all data declarations etc are printed out when found, so are the declarations themselves. No reason to keep them. Debug info for code follows the code itself. This is necessary, since the debug info must follow the reference to a place in the code stream, otherwise the debug info might refer to a label that is optimized away which is not acceptable by the assembler :-) -- Ragge
Re: Removing ARCNET stuffs
On Mon, Jun 08, 2015 at 04:15:15PM +0200, Anders Magnusson wrote: >> printfing from the back of the front end is definitely "totally wrong >> in other ways that need to be rectified first" :( > Hm, I may be missing something, but what is wrong? > Where should you print it out otherwise? I would say the debug information ought to be attached to the representation nodes it describes as it moves through the backend; otherwise it's easily upset by fairly simple transformations. but I don't claim to have ever implemented debugging support in a compiler, so don't pay too much attention... -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
David Holland skrev den 2015-06-03 07:56: > PCC, to the best of my knowledge is still in the [very early] planning > stages. One of its design choices would be to go pure SSA. Another > option, closer to GCC (RTL), would be to retain existing code-gen > passes. Tough choices. I'm not sure why it's such a big deal, except that everything in gcc is a big deal because gcc is such a mess inside. Moving an existing representation to SSA just requires adding phi nodes to the representation, writing a check pass to enforce the single assignment property, and updating existing passes to maintain the property -- in a language without proper algebraic data types this is a bigger deal than otherwise but it does not seem like a particularly major undertaking. Unless the representation is totally wrong in other ways that need to be rectified first. SSA representation was added to pcc in 2008. > > backend is an orthogonal issue. > > I'm being fast and loose. My reading of the code was that debug info > was being generated by the back of the front end (very roughly > "gimplify" in this diagram of GCC > https://gcc.gnu.org/projects/tree-ssa/#ssa). It was pretty much hard > wired printfs, and explained to me why "-g -O" wasn't supported. printfing from the back of the front end is definitely "totally wrong in other ways that need to be rectified first" :( Hm, I may be missing something, but what is wrong? Where should you print it out otherwise? -- Ragge
Re: Removing ARCNET stuffs
Andrew Cagney skrev den 2015-06-01 22:50:
Like I mentioned in another reply, I'm being a little fast and loose.
The file "cc/ccom/scan.l" from
http://pcc.ludd.ltu.se/fisheye/browse/pcc/pcc/cc/ccom/scan.l?r=1.127
which I'm assuming is the C parser is doing this:
#define STABS_LINE(x) if (gflag && cftnsp) stabs_line(x)
...
"\n"{ ++lineno; STABS_LINE(lineno); }
which, I believe, is executing this:
cprint(1, "\t.stabn %d,0,%d," STABLBL "\n" STABLBL ":\n",
N_SLINE, line, stablbl, stablbl);
and this will will insert the stab into the assembler stream
(send_passt). However, and here's the key thing, as best I can tell,
the stab isn't tied to an instruction, just a position in the
instruction stream.
It is tied to a statement (which is the only thing known at that time) in
the statement stream.
If an optimizer so much as sneezes, re-ordering instructions for
instance, the information is wrong.
Not necessarily, since the optimizer is quite aware about the existance
of debug info, and for stabs this is not a problem since it is
statement-based
and will always put the line label at the correct place regarding
statements.
If instructions between statements are interleaved we will always loose.
When the back-end goes to generate assembler, all it has, is a string.
Which is sufficient in this case. Another better way to do it would be to
tie the debug info to the statement struct, but it has not been any reason
to do that for stabs (which works well enough for normal debugging).
In the case of variables. They are generated at the start of a block,
so have no connection at all to the code.
perhaps I'm wrong?
They can be declared anywhere in the code, but nevertheless it do not matter
where as long as they refer to the correct function.
Note that the backend do not care about language, for example the f77
compiler
is included in the package. I haven't moved over the pascal frontend
yet though :-)
-- Ragge
Re: Removing ARCNET stuffs
Andrew Cagney skrev den 2015-06-01 20:41: On 1 June 2015 at 12:54, David Holland wrote: On Mon, Jun 01, 2015 at 11:41:38AM -0400, Andrew Cagney wrote: > >> systems and generates reasonable code. Unfortunately, and sorry PCC > >> (stabs, really?), > > > > Feel free to add dwarf, the source is out there, and it wouldn't be > > especially difficult to do it. I just haven't had time. > > Stabs was "for free" :-) > > I'm not so sure (a year back I looked at the code with that in mind), > and wonder if any quick hack would end up being opportunity lost. I have not looked at it, nor have I looked at pcc at all in a long time, so what I'm missing may just be otherwise obvious context, but: > PCC, as a "classic" C compiler, only generates debug information at > -O0. This this is because the stabs code is restricted to the > un-optimized code generator path. Having the backend restricted to > DWARF when '-O0' might just be ok, were it not for SSA (static single > assignment). > > To my mind, and I'm assuming a pure SSA compiler design, having SSA > forces issues like: [...] I'm missing something; SSA is just a style of program representation. Yes. Lets think of Static Single Assignment as the pure academic theory. LLVM[Lattner et.al.] and GIMPLE[Novillo et.al.] are real world implementations of that theory. https://gcc.gnu.org/projects/tree-ssa/#ssa has a good diagram and is a relevant read. PCC, to the best of my knowledge is still in the [very early] planning stages. One of its design choices would be to go pure SSA. Another option, closer to GCC (RTL), would be to retain existing code-gen passes. Tough choices. I do not understand why either of those choices need to be taken. Pcc has a reasonable intermediate representation, which in the optimizer is converted to SSA form, hammered on, and converted back. This is done while retaining the intermediate representation, which is no problem. I'm being fast and loose. My reading of the code was that debug info was being generated by the back of the front end (very roughly "gimplify" in this diagram of GCC https://gcc.gnu.org/projects/tree-ssa/#ssa). It was pretty much hard wired printfs, and explained to me why "-g -O" wasn't supported. printf's are only used for data (which is spit out directly), not code. All code is dealt with function-wise, otherwise things like the register allocator would not work. Unless, I guess, what you're talking about is throwing away the existing backend entirely and writing a new SSA-based one, in which case I'd gently suggest that this is a large project :-) Exactly :-( What is wrong with the existing backend? -- Ragge
Re: Removing ARCNET stuffs
Andrew Cagney skrev den 2015-06-01 17:41: On 1 June 2015 at 02:15, Anders Magnusson wrote: Andrew Cagney skrev den 2015-06-01 03:24: systems and generates reasonable code. Unfortunately, and sorry PCC (stabs, really?), Feel free to add dwarf, the source is out there, and it wouldn't be especially difficult to do it. I just haven't had time. Stabs was "for free" :-) I'm not so sure (a year back I looked at the code with that in mind), and wonder if any quick hack would end up being opportunity lost. PCC, as a "classic" C compiler, only generates debug information at -O0. This this is because the stabs code is restricted to the un-optimized code generator path. Having the backend restricted to DWARF when '-O0' might just be ok, were it not for SSA (static single assignment). I beg to differ. - There is no requirement to not use optimizations when debugging, and has not been so in recent years. - Why should it be any correlation to the debug format when using SSA representation or not? Just the SSA side of things (if debugging is ignored) is a lot of work (LLVM's solution was to largely ignore debugging. I once asked Lattner directly about this and he answered that he considered it a "back-end problem"). I must admit that I do not understand what would be the problem here. The SSA conversion (usually) only converts and moves stuff, which will not affect the debug info more than marginally. -- Ragge
Re: Removing ARCNET stuffs
On 3 June 2015 at 01:56, David Holland wrote: > On Mon, Jun 01, 2015 at 02:41:22PM -0400, Andrew Cagney wrote: > > > > To my mind, and I'm assuming a pure SSA compiler design, having SSA > > > > forces issues like: [...] > > > > > > I'm missing something; SSA is just a style of program representation. > > > > Yes. Lets think of Static Single Assignment as the pure academic theory. > > Ok... although calling it a "theory" is a bit much? Perhaps we can decide that by counting the number research papers and PHDs its generated :-) > It's just a scheme > for laying out program representations. A useful one for various > reasons; but it's not itself a representation and it doesn't have much > effect on the rest of the architecture of the compiler backend, except > maybe for naive backends. Right. Is that bad? Keep in mind that I think of RTL, based on having to on rare occasions prod it, as little more than glorified assembler. And even a little GCC probably corrupts my point-of-view :-) One of the debates for GCC was over doing as much as possible using the SSA representation vs keeping lots of [pre-existing] smarts in RTL Given GCC's architecture and the amount of existing intellectual and emotional investment in RTL, it was quickly off the table. > Or so it seems to me anyway, but I've been up to my ears in compiler > hokum in connection with a $WORK project for several years now. > > > PCC, to the best of my knowledge is still in the [very early] planning > > stages. One of its design choices would be to go pure SSA. Another > > option, closer to GCC (RTL), would be to retain existing code-gen > > passes. Tough choices. > > I'm not sure why it's such a big deal, except that everything in gcc > is a big deal because gcc is such a mess inside. >From my reading, the goal was to keep *all* existing architectures "working". Consequently, SSA was wedged into GCC in front of RTL. Thus preserving all the legacy. >From what your saying, PCC won't suffer from this and can integrate it directly into the existing framework. Much easier. > Moving an existing representation to SSA just requires adding phi > nodes to the representation, writing a check pass to enforce the > single assignment property, and updating existing passes to maintain > the property -- in a language without proper algebraic data types this > is a bigger deal than otherwise but it does not seem like a > particularly major undertaking. Unless the representation is totally > wrong in other ways that need to be rectified first. > > Maybe I'm missing something, or maybe I'm coming to this from a > strange point of view. > > > > Are you talking about a hypothetical future where pcc's backend grows > > > an (additional, or replacement) SSA-based layer? Or is pcc's > > > optimizing backend already SSA-based (per above, I don't know one way > > > or the other) and you're talking about making that preserve debug > > > info? > > > > > > Either way, it seems like adding DWARF support to the non-optimizing > > > backend is an orthogonal issue. > > > > I'm being fast and loose. My reading of the code was that debug info > > was being generated by the back of the front end (very roughly > > "gimplify" in this diagram of GCC > > https://gcc.gnu.org/projects/tree-ssa/#ssa). It was pretty much hard > > wired printfs, and explained to me why "-g -O" wasn't supported. > > printfing from the back of the front end is definitely "totally wrong > in other ways that need to be rectified first" :( Or view it as a clean slate. When SSA was added to GCC there was a perception that debugging became "worse". For instance, RTL always assigned things to contiguous registers so producers and consumers were both designed to assume this. SSA removed that limitation; it took longer for things to get back in sync. Part of the fallout was "-fvar-tracking", and one of the "great GCC debates" of 2007. GCC, with RTL, of course had more than double the challenge. While PCC should have nothing approaching those problems, you can perhaps see why I wonder if focusing first on SSA would be better. Fortunately it isn't my call. Andrew
Re: Removing ARCNET stuffs
On Wed, Jun 3, 2015 at 7:39 AM, Michael van Elst wrote: > jo...@britannica.bec.de (Joerg Sonnenberger) writes: > >>On Tue, Jun 02, 2015 at 11:47:01AM -0700, Dennis Ferguson wrote: >>> Asking for ARCNET support in the absence of hardware to test on, >>> however, is really asking for something quite different. Since you >>> can't make more than small, mechanical changes to anything and expect >>> it to work without testing (and I'm not even sure about the small, >>> mechanical changes) what is being asked instead is that nothing be >>> done that requires changes to the ARCNET code on the disk right >>> now, nor the framework it relies on to operate, while making it >>> someone else's problem to figure out how to deal with that constraint. >>> This isn't fair, and I don't think it has any possibility of working. > >>Amen. > > There are several NetBSD developers that own ARCNET hardware and > that could help out. You could also get new cards, at "industry" prices. > Okay, I have wanted to hear that. It would be helpful that someone try ARCNET occasionally whether it still works and alarm if we break something. Thanks, ozaki-r
Re: Removing ARCNET stuffs
On Mon, Jun 01, 2015 at 02:47:39PM -0400, Andrew Cagney wrote: > On 1 June 2015 at 13:50, David Holland wrote: > > but ignoring that -- who (other than apparently the gcc development > > team) is focusing on burning ram? > > GNU, this is from the GNU coding standard; to me it explains some of > the design choices I find in many GNU utilities: anyone *relevant*? :-) -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On Mon, Jun 01, 2015 at 02:41:22PM -0400, Andrew Cagney wrote: > > > To my mind, and I'm assuming a pure SSA compiler design, having SSA > > > forces issues like: [...] > > > > I'm missing something; SSA is just a style of program representation. > > Yes. Lets think of Static Single Assignment as the pure academic theory. Ok... although calling it a "theory" is a bit much? It's just a scheme for laying out program representations. A useful one for various reasons; but it's not itself a representation and it doesn't have much effect on the rest of the architecture of the compiler backend, except maybe for naive backends. Or so it seems to me anyway, but I've been up to my ears in compiler hokum in connection with a $WORK project for several years now. > PCC, to the best of my knowledge is still in the [very early] planning > stages. One of its design choices would be to go pure SSA. Another > option, closer to GCC (RTL), would be to retain existing code-gen > passes. Tough choices. I'm not sure why it's such a big deal, except that everything in gcc is a big deal because gcc is such a mess inside. Moving an existing representation to SSA just requires adding phi nodes to the representation, writing a check pass to enforce the single assignment property, and updating existing passes to maintain the property -- in a language without proper algebraic data types this is a bigger deal than otherwise but it does not seem like a particularly major undertaking. Unless the representation is totally wrong in other ways that need to be rectified first. Maybe I'm missing something, or maybe I'm coming to this from a strange point of view. > > Are you talking about a hypothetical future where pcc's backend grows > > an (additional, or replacement) SSA-based layer? Or is pcc's > > optimizing backend already SSA-based (per above, I don't know one way > > or the other) and you're talking about making that preserve debug > > info? > > > > Either way, it seems like adding DWARF support to the non-optimizing > > backend is an orthogonal issue. > > I'm being fast and loose. My reading of the code was that debug info > was being generated by the back of the front end (very roughly > "gimplify" in this diagram of GCC > https://gcc.gnu.org/projects/tree-ssa/#ssa). It was pretty much hard > wired printfs, and explained to me why "-g -O" wasn't supported. printfing from the back of the front end is definitely "totally wrong in other ways that need to be rectified first" :( -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On Sun, May 31, 2015 at 11:50:24AM +0100, Justin Cormack wrote: > On 31 May 2015 at 00:09, David Holland wrote: > > I'm saying that, fundamentally, if you want to run gcc4 or gcc5 on a > > Sparc IPC that you're going to have problems. There is no way around > > this, except maybe to float a new compiler with the specific goal of > > both being modern and running on 25-year-old hardware. (That's an > > enormous project.) > > I think pcc is currently the only realistic solution, but it still > needs a lot of work, > and we would want to do this without compromising support for gcc/clang, so > it means fixing pcc, as well as adding more architectures. (I would be happy > with a no c++ base system to support this). pcc has come a long way, and > we could get to a pcc base system for some architectures for 8.0 I think. Right; the question is to what extent this ends up making those architectures second-class. At some point (not necessarily this point) it becomes a de facto fork with most of the problems and none of the advantages of calling it one. Perhaps in place of "fork" read "two development branches" -- it certainly doesn't make sense to hold a schism and stop talking to one another in the sense of certain events of ~20 years ago. -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
jo...@britannica.bec.de (Joerg Sonnenberger) writes: >On Tue, Jun 02, 2015 at 11:47:01AM -0700, Dennis Ferguson wrote: >> Asking for ARCNET support in the absence of hardware to test on, >> however, is really asking for something quite different. Since you >> can't make more than small, mechanical changes to anything and expect >> it to work without testing (and I'm not even sure about the small, >> mechanical changes) what is being asked instead is that nothing be >> done that requires changes to the ARCNET code on the disk right >> now, nor the framework it relies on to operate, while making it >> someone else's problem to figure out how to deal with that constraint. >> This isn't fair, and I don't think it has any possibility of working. >Amen. There are several NetBSD developers that own ARCNET hardware and that could help out. You could also get new cards, at "industry" prices. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing ARCNET stuffs
"…small, mechanical changes"?? Famous last words. ;-> -dgl- On Jun 2, 2015, at 4:34 PM, Joerg Sonnenberger wrote: > On Tue, Jun 02, 2015 at 11:47:01AM -0700, Dennis Ferguson wrote: >> Asking for ARCNET support in the absence of hardware to test on, >> however, is really asking for something quite different. Since you >> can't make more than small, mechanical changes to anything and expect >> it to work without testing (and I'm not even sure about the small, >> mechanical changes) what is being asked instead is that nothing be >> done that requires changes to the ARCNET code on the disk right >> now, nor the framework it relies on to operate, while making it >> someone else's problem to figure out how to deal with that constraint. >> This isn't fair, and I don't think it has any possibility of working. > > Amen. > > Joerg
Re: Removing ARCNET stuffs
On Tue, Jun 02, 2015 at 11:47:01AM -0700, Dennis Ferguson wrote: > Asking for ARCNET support in the absence of hardware to test on, > however, is really asking for something quite different. Since you > can't make more than small, mechanical changes to anything and expect > it to work without testing (and I'm not even sure about the small, > mechanical changes) what is being asked instead is that nothing be > done that requires changes to the ARCNET code on the disk right > now, nor the framework it relies on to operate, while making it > someone else's problem to figure out how to deal with that constraint. > This isn't fair, and I don't think it has any possibility of working. Amen. Joerg
Re: Removing ARCNET stuffs
At Tue, 2 Jun 2015 11:47:01 -0700, Dennis Ferguson wrote: Subject: Re: Removing ARCNET stuffs > > It's too long an argument, but I think any approach to a > multiprocessor network stack that attempts to get there starting > with the existing network L2/L3/interface code as a base is likely > not on the table. I would offer the rather herculean effort spent > on FreeBSD to attempt to do exactly that, and the fairly mediocre > result it produced, as evidence. The resources to match that > probably don't exist, and if there were a better, easier way to do > this it would have been done already. I think the least cost way to > produce a better result is actually to make a big change, preserving > the device drivers and the transport protocol code (which needs to run > single-threaded per-socket in any case) and any non-IP protocol code > that still works (running single-threaded) but doing a wholesale > replacement of the code that moves packets between those things with > something that can operate without locks. Doing it this way has some > risks, not the least of which is that it would leave you with networking > code unlike anyone else's (though if it were well done I'm not sure this > would last, everyone has trouble with the network stack), but I think > this makes the problem tractable and has a good chance of producing > something that scales quite well even without a lot of Linux-style > micro-optimization effort. Dennis, if you are able I wonder if you could comment on how well you think the NetGraph implementation in FreeBSD fares with respect to being part of a multiprocessor network stack, and if you think it offers any advantages (and/or has any disadvantages) in an SMP environment. I understand that NetGraph gained some finer-grained SMP support as early as FreeBSD-5.x. I also read about some NetGraph locking and performance issues in the 201309DevSummit notes, but I don't know any of the details. What if NetGraph was the _only_ network stack in the kernel? And what about Luigi Rizzo's netmap? (which claims to be specifically targeted at multi-core machines) (I'm going to try to learn a bit more about netmap at BSDCan this year.) And finally, what about the possibilities for a more formal STREAMS-like implementation, or at least something that would be compatible with existing STREAMS modules at the API (DDI/DKI) level, w.r.t. SMP? This would maybe allow independent maintenance and testing of less widely used protocol modules (and perhaps even drivers) by third parties. -- Greg A. Woods Planix, Inc. +1 250 762-7675http://www.planix.com/ pgpjagMEFUHHu.pgp Description: PGP signature
Re: Removing ARCNET stuffs
On 30 May, 2015, at 16:09 , David Holland wrote: > In these cases, keeping the extra old stuff along with its > complications during the framework rototilling usually results in a > better framework; but it makes the rototilling cost a lot more. As the > amount of manpower available has been dropping and the urgency of > certain reconstruction projects (most notably, the multiprocessor > network stack) only increases, there's a point where it becomes a > choice: keep the old stuff, or do the reconstruction. I don't know if > we've actually hit that point yet with the arcnet code or not; > probably not, actually. But unless something changes, we'll get there > soon enough. And then the choice comes right down to the point at > issue: keep the old stuff, which has assorted benefits and enables > continuing use of the old hardware it's associated with, or do the > reconstruction, which is necessary to remain a credible platform for > production use on modern hardware. It's too long an argument, but I think any approach to a multiprocessor network stack that attempts to get there starting with the existing network L2/L3/interface code as a base is likely not on the table. I would offer the rather herculean effort spent on FreeBSD to attempt to do exactly that, and the fairly mediocre result it produced, as evidence. The resources to match that probably don't exist, and if there were a better, easier way to do this it would have been done already. I think the least cost way to produce a better result is actually to make a big change, preserving the device drivers and the transport protocol code (which needs to run single-threaded per-socket in any case) and any non-IP protocol code that still works (running single-threaded) but doing a wholesale replacement of the code that moves packets between those things with something that can operate without locks. Doing it this way has some risks, not the least of which is that it would leave you with networking code unlike anyone else's (though if it were well done I'm not sure this would last, everyone has trouble with the network stack), but I think this makes the problem tractable and has a good chance of producing something that scales quite well even without a lot of Linux-style micro-optimization effort. I also believe that you get a better, more complete result, if the network stack is well structured to make good use of a variety of interface hardware and makes supporting that variety as easy as possible, despite the fact that for a truly "modern" network stack very little other than Ethernet matters any more. For this reason I think ARCNET support (I'll bet token ring will come up at some point too, it has its own complexities) should stay. The thing is, though, that the requirement for continued support for ARCNET (or anything else) has got to be, more or less, a machine or two with ARCNET cards capable of running NetBSD, a not-NetBSD machine with an ARCNET card to talk to and a network to connect them. It isn't really possible to support anything without some way of running it to test it. Asking for ARCNET support in the absence of hardware to test on, however, is really asking for something quite different. Since you can't make more than small, mechanical changes to anything and expect it to work without testing (and I'm not even sure about the small, mechanical changes) what is being asked instead is that nothing be done that requires changes to the ARCNET code on the disk right now, nor the framework it relies on to operate, while making it someone else's problem to figure out how to deal with that constraint. This isn't fair, and I don't think it has any possibility of working. No one wants to break anything, but a consequence of changing code is that code will have to change. If the ARCNET code is in the bit that must change, and I believe it is, either there must be a way to test those changes or it must be discarded. If this can't be lived with then ARCNET-with-no-hardware-to-run-it-on is just a sideline issue and you should instead be asking yourself (seriously) the more fundamental question of whether you really want the networking code to change at all or are in fact happy with it just the way it is now, since the latter is a whole lot less work for everyone involved. So if you really want ARCNET or token ring to continue to be supported I think the best thing one could do to ensure that, and do everyone else a favour too, is to assemble the hardware required to test it while the hardware still exists. A plausible test harness might also work, though if there is no hardware to run it on I'm not sure I see the point. If this is too much effort but you still feel it must stay then maybe the best course is to minimize everyone's effort. Dennis Ferguson
Re: Removing ARCNET stuffs
On 1 June 2015 at 15:13, Iain Hibbert wrote:
> On Mon, 1 Jun 2015, Andrew Cagney wrote:
>
>> PCC, as a "classic" C compiler, only generates debug information at
>> -O0. This this is because the stabs code is restricted to the
>> un-optimized code generator path.
>
> this is not actually the case btw, and I don't recall it being like that
> in the last few years either..
Like I mentioned in another reply, I'm being a little fast and loose.
The file "cc/ccom/scan.l" from
http://pcc.ludd.ltu.se/fisheye/browse/pcc/pcc/cc/ccom/scan.l?r=1.127
which I'm assuming is the C parser is doing this:
#define STABS_LINE(x) if (gflag && cftnsp) stabs_line(x)
...
"\n"{ ++lineno; STABS_LINE(lineno); }
which, I believe, is executing this:
cprint(1, "\t.stabn %d,0,%d," STABLBL "\n" STABLBL ":\n",
N_SLINE, line, stablbl, stablbl);
and this will will insert the stab into the assembler stream
(send_passt). However, and here's the key thing, as best I can tell,
the stab isn't tied to an instruction, just a position in the
instruction stream.
If an optimizer so much as sneezes, re-ordering instructions for
instance, the information is wrong.
When the back-end goes to generate assembler, all it has, is a string.
In the case of variables. They are generated at the start of a block,
so have no connection at all to the code.
perhaps I'm wrong?
Andrew
> regards,
> iain
Re: Groff (was: Removing ARCNET stuffs)
On Mon, Jun 01, 2015 at 05:50:07PM +, David Holland wrote: > On Sun, May 31, 2015 at 09:24:48PM -0400, Andrew Cagney wrote: > > > (oh and please delete C++ groff, just replace it with that AWK script) > > which awk script? :-) > > (quite seriously, I've been looking for a while for an alternative to > groff for typesetting the miscellaneous articles in base. > (Delenda Carthago...) Once more, I will re-advertise that the complete Donald E. Knuth typesetting system is available, that can be even restricted to strictly just D.E.K.'s work (even with the fonts, this is a matter of far less than 10 MB); that is pure C89 (some auxiliaries invoke POSIX.2 utilities, mainly sh(1) but these are just auxiliaries); that comes with the fonts, the ability to design the fonts, the formatting (TeX) and a format dvi à la PDF that can be used to generate a formatted text version; the means to use also mathematics; the means to draw figures rasterized with METAFONT (more general figures with MetaPOST, supplementary, but this generates PS); and with a compiling framework that is not GPLn but BSD. Since for a system written in C the main "human" language is "CEE" that is a kind of technical english, the limitation to 8 bits (that could be changed by dealing with font directories and not font files, i.e. a directory of 256 glyphes sub-font) is not an immediate problem. The conversion from roff to tex should be easier than the reverse and I expect relatively simple for 95% of the work (the man pages). IMHO, the main tasks remaining are (could be GSoC by the way): - give a DVI viewer (starting from scratch); - extend with the minimal changes TeX to be able to use UTF-8 (meaning, as UTF-8, that ASCII can be fed as is, but that this is just 8 bits still at entry---mouth); - whether develop a C SmallScript to be able to interpret the limited MetaPOST PostScript; or extend DVI and METAFONT to handle MetaPOST capabilities and rasterize the figures, in order for the system to be totally self-sufficient (no PDF viewer or PostScript interpreter to be able to render the pages). It is here: http://www.kergis.com/en/kertex.html It is not orphaned but stalled for the moment due to ETIME. Best, -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Removing ARCNET stuffs
On 5/30/15 6:16 PM, David Holland wrote: > My thought is that rather than shim layers we (fsvo "we") ought to be > aggressively producing an alternative design, with the goal of getting > it to the point where application developers take notice instead of > robotically following where gnome/kde lead. Lumina [1]? Lewis [1] http://blog.pcbsd.org/2015/05/lumina-desktop-status-updatefaq/
Re: Removing ARCNET stuffs
On Mon, 1 Jun 2015, Andrew Cagney wrote: > PCC, as a "classic" C compiler, only generates debug information at > -O0. This this is because the stabs code is restricted to the > un-optimized code generator path. this is not actually the case btw, and I don't recall it being like that in the last few years either.. regards, iain
Re: Removing ARCNET stuffs
> > (oh and please delete C++ groff, just replace it with that AWK script) > > which awk script? :-) > > (quite seriously, I've been looking for a while for an alternative to > groff for typesetting the miscellaneous articles in base. I was thinking of http://doc.cat-v.org/henry_spencer/awf/ which I understand was adopted by MINIX. I'm sure there are other choices. Andrew
Re: Removing ARCNET stuffs
On 1 June 2015 at 13:50, David Holland wrote: > but ignoring that -- who (other than apparently the gcc development > team) is focusing on burning ram? GNU, this is from the GNU coding standard; to me it explains some of the design choices I find in many GNU utilities: "For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). "
Re: Removing ARCNET stuffs
On 1 June 2015 at 12:54, David Holland wrote: > On Mon, Jun 01, 2015 at 11:41:38AM -0400, Andrew Cagney wrote: > > >> systems and generates reasonable code. Unfortunately, and sorry PCC > > >> (stabs, really?), > > > > > > Feel free to add dwarf, the source is out there, and it wouldn't be > > > especially difficult to do it. I just haven't had time. > > > Stabs was "for free" :-) > > > > I'm not so sure (a year back I looked at the code with that in mind), > > and wonder if any quick hack would end up being opportunity lost. > > I have not looked at it, nor have I looked at pcc at all in a long > time, so what I'm missing may just be otherwise obvious context, but: > > > PCC, as a "classic" C compiler, only generates debug information at > > -O0. This this is because the stabs code is restricted to the > > un-optimized code generator path. Having the backend restricted to > > DWARF when '-O0' might just be ok, were it not for SSA (static single > > assignment). > > > > To my mind, and I'm assuming a pure SSA compiler design, having SSA > > forces issues like: [...] > > I'm missing something; SSA is just a style of program representation. Yes. Lets think of Static Single Assignment as the pure academic theory. LLVM[Lattner et.al.] and GIMPLE[Novillo et.al.] are real world implementations of that theory. https://gcc.gnu.org/projects/tree-ssa/#ssa has a good diagram and is a relevant read. PCC, to the best of my knowledge is still in the [very early] planning stages. One of its design choices would be to go pure SSA. Another option, closer to GCC (RTL), would be to retain existing code-gen passes. Tough choices. > Are you talking about a hypothetical future where pcc's backend grows > an (additional, or replacement) SSA-based layer? Or is pcc's > optimizing backend already SSA-based (per above, I don't know one way > or the other) and you're talking about making that preserve debug > info? > > Either way, it seems like adding DWARF support to the non-optimizing > backend is an orthogonal issue. I'm being fast and loose. My reading of the code was that debug info was being generated by the back of the front end (very roughly "gimplify" in this diagram of GCC https://gcc.gnu.org/projects/tree-ssa/#ssa). It was pretty much hard wired printfs, and explained to me why "-g -O" wasn't supported. > Unless, I guess, what you're talking about is throwing away the > existing backend entirely and writing a new SSA-based one, in which > case I'd gently suggest that this is a large project :-) Exactly :-( Andrew > > > (I've got to admit that I wonder if C is the best language for an > > optimizing compiler; but then, it is what we have) > > It is not, but one can do a lot worse. Plus if you try you end up in > bootstrap hell like e.g. lang/ghc. > > -- > David A. Holland > dholl...@netbsd.org
Re: Removing ARCNET stuffs
On Sun, May 31, 2015 at 09:24:48PM -0400, Andrew Cagney wrote: > On 30 May 2015 at 19:09, David Holland wrote: > > The reason I floated the idea of forking is that an OS that's > > specifically intended to be a high-quality Unix for older hardware can > > make a different set of decisions (most notably, it can let C++ go > > hang) and this allows avoiding a wide and growing range of problems > > that currently affect NetBSD on old hardware. Meanwhile, it would also > > (one hopes) allow retaining a critical mass of retrocomputing > > enthusiasts in one place, as opposed to having them all gradually > > drift away in different directions. > > Perhaps there are several, for want of a better phrase, "niche" plays here: > > - remove C++ from base; Since when was UNIX's system compiler C++ While killing off C++ would be a great thing on all kinds of grounds, it isn't practical. If we removed C++ from base one of the first things nearly everyone would have to do is build a C++ compiler from pkgsrc; this is pointless. Also, since nowadays both gcc and clang require C++ to build, it's highly problematic: one would need to begin by downloading bootstrap binaries. Too much 3rd-party software (including high-demand things like Firefox) is written in C++. An OS that's specifically not meant to host such things can blow that off, but NetBSD per se is not and is very unlikely to ever be such an OS. > (oh and please delete C++ groff, just replace it with that AWK script) which awk script? :-) (quite seriously, I've been looking for a while for an alternative to groff for typesetting the miscellaneous articles in base. > - focus more on, and sorry for the marketing term, "scalability" > > That is being able to run things on smaller and larger systems. This > means more focus to algorithms and choices, and less focus on burning > ram like no tomorrow. That's not what "scalability" means out in the real word; there it means "running on as many CPUs as possible". but ignoring that -- who (other than apparently the gcc development team) is focusing on burning ram? As I've already said a couple times I'm sure there are places in NetBSD that are gratuitously slow for no reason other than it's imperceptible on the hardware most developers use for development. I at least am happy to fix these when they're found; but I'm not in a position to find them and nobody in general seems to be looking. Similarly, it's certainly the case that the system's been expanding over the years and that some of this is bloat; however, finding actual instances of bloat is not so easy. Finding features that have been added is easier; but most of those were added for a reason and/or someone is using, so simply pruning them back isn't feasible. A system whose specific goal is to make like 1990s Unix (or 1980s Unix) can make fundamentally different decisions about things like this -- as an obvious example it probably isn't necessary for such a system to scale past say 16 processors, so a lot of the complicated machinery that currently exists in pursuit of scaling could be reverted. That alone would make a noticeable difference. > - look at, cough, simulators, cough, as a way to test and develop for > less mainstream architectures > > The build process is sick, figuring out how to get it running on QEMU, > say, isn't. Can this work, consistently, across all platforms: > > qemu-system-XXX -nographic -kernel > sys/arch/XXX/compile/QEMU/netbsd -cdrom releasedir/... -sd0 disk.img No, it can't. But it would certainly be helpful to have top-level rules to set up and boot test images. Currently you can use "anita install" and "anita interact" for this, sort of, on some targets, but it doesn't integrate too well with the build system. Being able to do ./build.sh release ./build.sh live-image ./build.sh boot-live-image would be nice. Or since live-image may have usage constraints that make it not what one wants for hacking, ./build.sh release ./build.sh test-image ./build.sh boot-test-image and maybe ./build.sh test-image-kernel=TEST ./build.sh boot-test-image to make for shorter build/test cycles. (At least for x86 and qemu, this involves using a second disk image to hold the kernel -- the qemu -kernel foo thing only works for Linux kernels. I have found that keeping a third disk image around for scratch files that persist across image regeneration is worthwhile too.) I don't think there's any reason this can't be done; it just hasn't been. It needs a fair amount of target-specific logic to be useful, as the emulator of choice often isn't qemu; but getting that logic into a central place instead of dispersed among private scripts belonging to individual developers would be a step forward. Developing mostly on emulators though has a way of leading to the real hardware not actually working. This has already happened a few times. :-| -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On Mon, Jun 01, 2015 at 11:41:38AM -0400, Andrew Cagney wrote: > >> systems and generates reasonable code. Unfortunately, and sorry PCC > >> (stabs, really?), > > > > Feel free to add dwarf, the source is out there, and it wouldn't be > > especially difficult to do it. I just haven't had time. > > Stabs was "for free" :-) > > I'm not so sure (a year back I looked at the code with that in mind), > and wonder if any quick hack would end up being opportunity lost. I have not looked at it, nor have I looked at pcc at all in a long time, so what I'm missing may just be otherwise obvious context, but: > PCC, as a "classic" C compiler, only generates debug information at > -O0. This this is because the stabs code is restricted to the > un-optimized code generator path. Having the backend restricted to > DWARF when '-O0' might just be ok, were it not for SSA (static single > assignment). > > To my mind, and I'm assuming a pure SSA compiler design, having SSA > forces issues like: [...] I'm missing something; SSA is just a style of program representation. Are you talking about a hypothetical future where pcc's backend grows an (additional, or replacement) SSA-based layer? Or is pcc's optimizing backend already SSA-based (per above, I don't know one way or the other) and you're talking about making that preserve debug info? Either way, it seems like adding DWARF support to the non-optimizing backend is an orthogonal issue. Unless, I guess, what you're talking about is throwing away the existing backend entirely and writing a new SSA-based one, in which case I'd gently suggest that this is a large project :-) > (I've got to admit that I wonder if C is the best language for an > optimizing compiler; but then, it is what we have) It is not, but one can do a lot worse. Plus if you try you end up in bootstrap hell like e.g. lang/ghc. -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On 1 June 2015 at 02:15, Anders Magnusson wrote: > Andrew Cagney skrev den 2015-06-01 03:24: >> >> systems and generates reasonable code. Unfortunately, and sorry PCC >> (stabs, really?), > > Feel free to add dwarf, the source is out there, and it wouldn't be > especially difficult to do it. I just haven't had time. > Stabs was "for free" :-) I'm not so sure (a year back I looked at the code with that in mind), and wonder if any quick hack would end up being opportunity lost. PCC, as a "classic" C compiler, only generates debug information at -O0. This this is because the stabs code is restricted to the un-optimized code generator path. Having the backend restricted to DWARF when '-O0' might just be ok, were it not for SSA (static single assignment). To my mind, and I'm assuming a pure SSA compiler design, having SSA forces issues like: - new back-ends that talk SSA (GCC still seems to be unable to eliminate RTL); and one day generate debug information - intermediate debug information paired with the SSA so that, at -O0, "front end -> SSA -> backend" can generate debug information - the expectation that "-O -g" works - untouched SSA results in code far far worse than PCC at -O0 (the basic backend has a lot of smarts that deserve credit) Just the SSA side of things (if debugging is ignored) is a lot of work (LLVM's solution was to largely ignore debugging. I once asked Lattner directly about this and he answered that he considered it a "back-end problem"). If PCC starts generating DWARF then be sure I'll find and report bugs; however I think that would be a distraction. Andrew (I've got to admit that I wonder if C is the best language for an optimizing compiler; but then, it is what we have)
Re: Removing ARCNET stuffs
Antti Kantee wrote: > On 31/05/15 06:05, matthew green wrote: > > hi Andrew! :) > > > >> Who is appalled to discover that pc532 support has been removed! > > In addition to toolchain support, the hardware was near-extinct at the > time of removal. That prompted me to turn the old beast on. Apart from the quite alarming whine from the SCSI drive, she still fires up: pc532:~ 1> date ; uname -a Mon Jun 1 23:00:08 EST 2015 NetBSD pc532.thistledown.com.au 4.99.1 NetBSD 4.99.1 (PC532) #251: Wed Sep 6 15:54:11 EST 2006 sim...@thoreau.thistledown.com.au:/var/tmp/KERNELS/PC532 pc532 pc532:~ 2> We now return you to your normal programming... Cheers, Simon.
Re: Removing ARCNET stuffs
On Fri, 29 May 2015 12:22:40 +0200, Johnny Billquist wrote: > On 2015-05-29 08:18, Matt Thomas wrote: > > > > I have a Phase IV+ (so I didn't have to much with the physical address) impl ementation but never got around to writing the apps. socket interface is ident ical to DECnet-ULTRIX. DAP is a beast as is CTERM. I could run IP protocols o ver, but then I have IP for that. :) > > I never committed it because I doubted there was interest. Itâs probably > > bi t rotted but I could resurrect it. > > Well, me for one would be interested... > Mee too. It would not include LAT though, would it? Anders
Re: Removing ARCNET stuffs
Andrew Cagney skrev den 2015-06-01 03:24: systems and generates reasonable code. Unfortunately, and sorry PCC (stabs, really?), Feel free to add dwarf, the source is out there, and it wouldn't be especially difficult to do it. I just haven't had time. Stabs was "for free" :-) -- Ragge
Re: Removing ARCNET stuffs
On 30 May 2015 at 19:09, David Holland wrote: > The reason I floated the idea of forking is that an OS that's > specifically intended to be a high-quality Unix for older hardware can > make a different set of decisions (most notably, it can let C++ go > hang) and this allows avoiding a wide and growing range of problems > that currently affect NetBSD on old hardware. Meanwhile, it would also > (one hopes) allow retaining a critical mass of retrocomputing > enthusiasts in one place, as opposed to having them all gradually > drift away in different directions. Perhaps there are several, for want of a better phrase, "niche" plays here: - remove C++ from base; Since when was UNIX's system compiler C++ Instead there should be small fast modern C compiler that runs on all systems and generates reasonable code. Unfortunately, and sorry PCC (stabs, really?), this one currently doesn't exist, and no one seems to have the time to make it exist, sigh. This isn't to say that NetBSD shouldn't be cross-buildable using GNU or LLVM, just that the above be the default compiler. FreeBSD has clearly nailed itself to LLVM+LLDB and that means a C++ system compiler, and that, in turn means slow compiles on recent machines with lots of ram. And on a related note, the GNU tools - GCC, GOLD, GDB (https://sourceware.org/gdb/wiki/cxx-conversion) - which tend to be used here - are are now all also members of the C++ Borg (is it only time before binutils gets assimilated? :-) so if NetBSD does nothing, it will find itself being lead down FreeBSD's C++ path. (oh and please delete C++ groff, just replace it with that AWK script) - focus more on, and sorry for the marketing term, "scalability" That is being able to run things on smaller and larger systems. This means more focus to algorithms and choices, and less focus on burning ram like no tomorrow. - look at, cough, simulators, cough, as a way to test and develop for less mainstream architectures The build process is sick, figuring out how to get it running on QEMU, say, isn't. Can this work, consistently, across all platforms: qemu-system-XXX -nographic -kernel sys/arch/XXX/compile/QEMU/netbsd -cdrom releasedir/... -sd0 disk.img Andrew
Re: Removing ARCNET stuffs
Yes, I'm being hypocritical :-) On 31 May 2015 at 02:05, matthew green wrote: > > hi Andrew! :) > >> Who is appalled to discover that pc532 support has been removed! > > get your GCC and binutils and GDB pals to put the support back > in the toolchain and we'll have something to talk about :-) > note that we've revived the playstation2 port now that its has > had its toolchain components finally appear in mainline ... ;) Right. It takes time, effort and motivation to maintain code. Not people lamenting lost history :-) -- For reference, this is what I wrote in 2004, when starting the process of removing ns32k support when starting the process of removing NS32k support. It was two releases and roughly another year before the code was completely removed. It probably serves as a useful study given what is being discussed here - extra infrastructure to prop up dieing code just delayed the inevitable :-) * END-OF-LIFE frame compatibility module GDB's internal frame infrastructure has been completely rewritten. The new infrastructure making it possible to support key new features including DWARF 2 Call Frame Information. To aid in the task of migrating old configurations to this new infrastructure, a compatibility module, that allowed old configurations to continue to work, was also included. GDB 6.2 will be the last release to include this frame compatibility module. This change directly impacts the following configurations: h8300-*-* mcore-*-* mn10300-*-* ns32k-*-* sh64-*-* v850-*-* xstormy16-*-*
Re: Removing ARCNET stuffs
Antti Kantee wrote: > On 31/05/15 06:05, matthew green wrote: > > hi Andrew! :) > > > >> Who is appalled to discover that pc532 support has been removed! > > In addition to toolchain support, the hardware was near-extinct at the > time of removal. > > Now, the hardware is no longer near-extinct: > http://cpu-ns32k.net/ > > I used the FPGA pc532 running NetBSD 1.5.x(?) a few weeks back. > Unbelievable experience, especially since I spent quite some time and > effort trying to get a pc532 I had on loan 10+ years ago to function. > > > get your GCC and binutils and GDB pals to put the support back > > in the toolchain and we'll have something to talk about :-) > > Didn't know that things to *talk* about were short in supply... > I was looking for the so called open-source resources of pc532. Can we put it somewhere on the web again? Last time I was checking (not so long ago) and they were off-line. At the moment I'm focused on acorn26, I obtained RISCOS. This port should be saved to put fun into the computing. I work at work with newer ARM CPUs, but the basic ideas are the same in ARMv2/v3 (IRQ, FIQ, RISC, etc) - this isn't only fun but also good for learning - even though I will be just in the platform emulator. Personally (sorry for this) I don't like pcc, so I started clank [1], a clang/llvm clone in plain C with the goal of minimal possible footprint, supporting exclusively the C language, being portable (-lnbcompat) and with interchangeable with clang/llvm compiler parts - being as close to the original as possible to track upstream... I want to save sun2, deC++ base (as the MK option) and in general get acquainted with the llvm internals. This is rather long-term project just in a spare time. Lost of time? Probably, but even in this very early stage I can catch places for enhancement in the big-brother clang/llvm [2]. David, forking NetBSD? Usually teams are more powerful than individuals and they win at end. Forks are valuable only then when they will attract new people and submit patches back to upstream -- this is a relation between DragonflyBSD and FreeBSD. There is also EdgeBSD [3] a good project to prototype features in git. I can see a market share in desktops, I belive we need better support for recent DE, graphical installer (calamares.io is my choice for a NetBSD livecd with preinstalled packages). As someone already stated, if we aren't on desktops we aren't anywhere else. I saw that companies put Ubuntu (ubuntu-core) even on your PCI peripherals, just because people are familiar with this system. This is the reason why I'm for winning back desktop. What to do to make the project easier for newcomers - from a stand point of a new wannabe developer? Improving the contribution platform - well, I am aware of the fact that people are used to the same techniques like in nineties and have the standards set in stone. I can see the following problems: - no central location for patches -- several mailing-lists, PR, private-mails.. - no way to track pending patches -- except pinging developers.. - no standard patch format - extra work on developers to maintain it My proposition is (expressed already before) to set official GitHub mirror and accept there patches and issues at dedicated git branches. I almost stopped to contribute my patches to projects if they are outside GitHub, mailing lists are extra burden to register an account, track traffic, spam and general noise. With the GitHub platform the cost of maintainership will be higher on start and quite low later. No need for extra internal infrastructure except scheduled cvs2git script. [1] https://github.com/krytarowski/clank [2] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150209/258953.html [3] http://edgebsd.org/
Re: Removing ARCNET stuffs
On 31/05/15 06:05, matthew green wrote: hi Andrew! :) Who is appalled to discover that pc532 support has been removed! In addition to toolchain support, the hardware was near-extinct at the time of removal. Now, the hardware is no longer near-extinct: http://cpu-ns32k.net/ I used the FPGA pc532 running NetBSD 1.5.x(?) a few weeks back. Unbelievable experience, especially since I spent quite some time and effort trying to get a pc532 I had on loan 10+ years ago to function. get your GCC and binutils and GDB pals to put the support back in the toolchain and we'll have something to talk about :-) Didn't know that things to *talk* about were short in supply...
Re: Removing ARCNET stuffs
On 31 May 2015 at 00:09, David Holland wrote: > I'm saying that, fundamentally, if you want to run gcc4 or gcc5 on a > Sparc IPC that you're going to have problems. There is no way around > this, except maybe to float a new compiler with the specific goal of > both being modern and running on 25-year-old hardware. (That's an > enormous project.) I think pcc is currently the only realistic solution, but it still needs a lot of work, and we would want to do this without compromising support for gcc/clang, so it means fixing pcc, as well as adding more architectures. (I would be happy with a no c++ base system to support this). pcc has come a long way, and we could get to a pcc base system for some architectures for 8.0 I think. Justin
re: Removing ARCNET stuffs
hi Andrew! :) > Who is appalled to discover that pc532 support has been removed! get your GCC and binutils and GDB pals to put the support back in the toolchain and we'll have something to talk about :-) note that we've revived the playstation2 port now that its has had its toolchain components finally appear in mainline ... ;) .mrg.
Re: Removing ARCNET stuffs
Hi, On Sat, May 30, 2015 at 07:37:04PM +, David Holland wrote: > > I would argue that this has happened already - FreeBSD and NetBSD are > > the results... at least from the outside, this is how it looks like, > > with FreeBSD focusing on few platforms but modernizing itself quite > > a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs > > everywhere". > > Yes, see, this is the problem. "It runs everywhere" now means "it is > an OS for junkyard machines". That was never the intent when that was > NetBSD's market positioning, 15+ years ago. Nor is it the reality now. This is not what I said "for junkyard machines". It does run on amd64 as well, after all :-) But you can't really argue the point that priorities are quite different here - "focused on portability, really good cross-build system, etc." vs. "newest features and maximum efficiency on modern hardware". [..] > > Now, speaking as application developer: I'd hate to see yet another BSD > > fork that I have to test OpenVPN on regularily, to see whether "we" or > > "they" broke something and system-specific parts need to be adjusted... > > (right now, we build and test on FreeBSD, NetBSD and OpenBSD, and > > various versions of those - sufficiently subtly different that there > > has to be system-specific code for ifconfig/route handling...) > > Dragonfly? What about all the OpenBSD offshoots? >From an API point of view, Dragonfly seems to be very close to FreeBSD (all our code has #if defined(TARGET_FREEBSD) || defined(TARGET_DRAGONFLY), though I've never personally tested Dragonfly) - and until someone shows up and asks us about supporting yet another OpenBSD offshot, I'm not going to care. But indeed, there are already way too many BSD forks out there to even try to build and test on all of them regularily. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: Removing ARCNET stuffs
There's a complex tradeoff here On 29 May 2015 at 12:09, J. Lewis Muir wrote: > In "Evolving Frameworks," [2] Don Roberts and Ralph Johnson suggest > in the "Tree Examples" pattern that you should never write a software > framework unless you have at least three applications that use it. Part > of the reasoning is that these applications help you come up with the > proper abstractions for the framework. If you think of NetBSD as a > framework and the machine architectures and hardware as applications, > then perhaps all of those "applications" can actually be a benefit to > NetBSD and help it to have really nice abstractions and design. Each new application that uses the framework adds "drag", slowing the framework's ability to evolve; while some of that drag is due to code, a surprising amount is politics. Each time the framework is changed there's probabilistic risk that an application breaks. The real problem, though, is when no one notices, yet demands that the application be maintain continue loud and clear. Here's a suggestion: - as part of proposing that code be removed, provide supporting evidence of when/why it broke - and conversely, anyone suggesting that the bug is an easy fix, back that up with a test platform so this can be confirmed Based on experience, if there is evidence of long-broken code (as in several major releases back) then this is just the start of the problems. If the functionality (not the code) really is worth salvaging then that is something better to do _after_ the overhaul that caused this to be flushed out. Andrew Who is appalled to discover that pc532 support has been removed!
Re: Removing ARCNET stuffs
On Sat, May 30, 2015 at 10:45:59PM +0100, Dave Tyson wrote: > I am with Gerald on this. Having used NetBSD from 0.8 I really appreciate > the single source tree for all architectures and the ability to cross build > painlessly from different platforms. I also like the community and the fact > that I can generally sort out problems by searching the lists or asking on > the lists. Having had to do battle with Linux occasionally I have been > frustrated by the vast amount of conflicting information thrown up by a > google search on a problem... Nobody wants to change any of this :-) > One concern I do have is the linuxification of a lot of big applications - > the likes on KDE etc. These seem to be heading down the road of being > strongly dependant on kludges like systemd. I despair that these will kill > off the ability to use NetBSD as a desktop system unless a suitable shim > layer can be produced which provides the information to the application > without the stupid windows methodology in the kernel. My thought is that rather than shim layers we (fsvo "we") ought to be aggressively producing an alternative design, with the goal of getting it to the point where application developers take notice instead of robotically following where gnome/kde lead. Of course, it's easy to say that and I haven't had time lately to work on NetBSD much let alone wild blue-sky ideas. -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On Sat, May 30, 2015 at 10:45:46PM +0200, Gert Doering wrote: > On Sat, May 30, 2015 at 07:37:04PM +, David Holland wrote: > > > I would argue that this has happened already - FreeBSD and NetBSD are > > > the results... at least from the outside, this is how it looks like, > > > with FreeBSD focusing on few platforms but modernizing itself quite > > > a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs > > > everywhere". > > > > Yes, see, this is the problem. "It runs everywhere" now means "it is > > an OS for junkyard machines". That was never the intent when that was > > NetBSD's market positioning, 15+ years ago. Nor is it the reality now. > > This is not what I said "for junkyard machines". It does run on amd64 > as well, after all :-) > > But you can't really argue the point that priorities are quite different > here - "focused on portability, really good cross-build system, etc." > vs. "newest features and maximum efficiency on modern hardware". Yes, I can. That's all market positioning from 15-20 years ago; it has little or no current relevance, either for NetBSD or FreeBSD. > and until someone shows > up and asks us about supporting yet another OpenBSD offshot, I'm not going > to care. Fair enough :-) -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On Sat, May 30, 2015 at 11:05:30PM +0200, Johnny Billquist wrote: > > > I would argue that this has happened already - FreeBSD and NetBSD are > > > the results... at least from the outside, this is how it looks like, > > > with FreeBSD focusing on few platforms but modernizing itself quite > > > a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs > > > everywhere". > > > > Yes, see, this is the problem. "It runs everywhere" now means "it is > > an OS for junkyard machines". That was never the intent when that was > > NetBSD's market positioning, 15+ years ago. Nor is it the reality now. > > We have different views here. Do we? My position on this subject is somewhat complicated and not well aired, but you do realize that for years I've been arguing against removing things just because they're old, right? I used the term "junkyard machines" in that bit deliberately, because that's what the perception of NetBSD is becoming (or has become) in a number of quarters: an obsolete operating system suitable for using on obsolete hardware, and therefore not to be taken seriously and not worth much of anything. > In my eyes, these "junkyard" machines have forced NetBSD to keep > somewhat honest. Yes. That's why we still have the sun2 port, for example. That's why I have (though not recently) put some time towards doing a port to a 36-bit machine. And why if possible we shouldn't remove arcnet. Hanging these things on a fundamentally sound framework adds little cost and helps to keep the framework sound. There are two problems though: first, when the framework is not sound, the extra stuff hanging on (and particularly, the complications that arise from less elegant phenomena that appear only in old material, VIVT caches being one example) can substantially increase the cost of working on the framework. Many of the removal proposals arise from this: this one, for example, as well as the intermittent suggestions to prune old m68k ports. This is also part of why softupdates got removed. In these cases, keeping the extra old stuff along with its complications during the framework rototilling usually results in a better framework; but it makes the rototilling cost a lot more. As the amount of manpower available has been dropping and the urgency of certain reconstruction projects (most notably, the multiprocessor network stack) only increases, there's a point where it becomes a choice: keep the old stuff, or do the reconstruction. I don't know if we've actually hit that point yet with the arcnet code or not; probably not, actually. But unless something changes, we'll get there soon enough. And then the choice comes right down to the point at issue: keep the old stuff, which has assorted benefits and enables continuing use of the old hardware it's associated with, or do the reconstruction, which is necessary to remain a credible platform for production use on modern hardware. Whether or not we've reached it yet, there will fairly soon be a point where "both" isn't an option. And then what? As much as the retrocomputing users are a fairly important chunk of the NetBSD user base, I don't think abandoning the claim/intent to be a serious modern platform will sit well with the developer community. If we don't come to some kind of resolution, most likely the same things will happen that have happened in the recent past: NetBSD must do X and Y in order to remain a serious platform, so NetBSD does X and Y, and because of the negative consequences on retrocomputing platforms a chunk of that community drifts away. This process helps nobody. Meanwhile, the second problem (arising from instances of this same process) is that "honest" or not, NetBSD is no longer really a viable platform for the oldest hardware. This is most notable if you try to run the compiler: gcc 4.8 is just too big to behave acceptably on a slow and small platform. (And clang, if anything, is worse.) NetBSD cannot roll back to an older and smaller compiler, for a number of reasons the most difficult of which is that delightful moving target known as Standard C++. We could ship pcc as the system compiler for certain ports; but that doesn't really fix the problem (only hides it) and makes those ports fundamentally second class in a way that nobody will like. A similar problem exists with X, because upstream keeps dropping support for "old" (as in 10-year-old, not 30) graphics hardware. The reason I floated the idea of forking is that an OS that's specifically intended to be a high-quality Unix for older hardware can make a different set of decisions (most notably, it can let C++ go hang) and this allows avoiding a wide and growing range of problems that currently affect NetBSD on old hardware. Meanwhile, it would also (one hopes) allow retaining a critical mass of retrocomputing enthusiasts in one place, as opposed to having them all gradually drift away in different directions. I'm not at all convinced it's a good idea; but n
Re: Removing ARCNET stuffs
On 05/29/15 20:15, Gerard Lally wrote: At date and time Fri, 29 May 2015 11:09:08 -0500, J. Lewis Muir wrote: On 5/29/15 5:22 AM, David Holland wrote: Because of these trends, I've been thinking for a while now that maybe it's getting to be time to fork. Hello, David! I started using NetBSD because of its small base system disk and memory footprint, focus on security, support for many machine architectures, ability to scale well to large SMP machines, support for a wide range of deployments from embedded to server to desktop (it's a big time savings to only have to learn and remember how to do something on one OS instead of many), and genteel user and developer community. I value all of these things. (Some benefits I came to appreciate later were its relatively long support for a release and its package management system, pkgsrc (writing a package once and having it work on all platforms I use is a big win).) [...] I sometimes think developers get so close they can't see the wood for the trees. They see all the flaws but fail to see the overall picture. As someone who struggles to understand code I am happily oblivious of NetBSD's flaws. What I can say, however, is that using NetBSD is so much more pleasant than using any of the modern Linux distributions, with the honourable exception of Crux and Slackware. I tried the latest Debian and CentOS recently and I wanted to throw up. Talk about over-engineering, deliberate obfuscation and condescension! It would be a tragedy of immense proportions to see NetBSD's small developer pool split up to pursue their own interests in yet another BSD fork. They have put together a first-rate, unequalled operating system that really is a pleasure to use. I for one didn't need marketing in order to find NetBSD; the sheer stupidity of other open-source operating systems was enough to drive me here. Why the need for marketing? We are intelligent enough to discover NetBSD for ourselves without marketing. If it does what we want then we stay with it. Simple. Is it really worth it putting the future of the project at risk over these small quarrels that pop up every now and again? Perhaps Ryota Ozaki could quantify the cost of maintaining this code? If it appears too costly then should we really go all out to maintain it, given what Ryota is offering in its stead - a multiprocessor-friendly network stack? Surely the pros have to be weighed up here, as well as the cons? Just my tuppence worth. NetBSD is to my mind nearly perfect. Adding a modern network stack, a modern filesystem and perhaps some MAC implementation (or do we already have that?) would make it unequalled. If we need to sacrifice some code along the way shouldn't we be prepared to do so? People will naturally gravitate towards excellence if it is provided, no marketing required. Let's keep the developer pool together, and let's not get all worked up over code if Ryota feels a multiprocessor network stack can't be easily achieved while it's in place. The pursuit of excellence is not always immediately rewarding, and some people stand to lose out for the greater good. That's life. No need for drama; let's make a mature decision about this and be grateful we still have NetBSD to work and play with, because, for me at least, 95% of the alternatives are rapidly heading for the gutter. I am with Gerald on this. Having used NetBSD from 0.8 I really appreciate the single source tree for all architectures and the ability to cross build painlessly from different platforms. I also like the community and the fact that I can generally sort out problems by searching the lists or asking on the lists. Having had to do battle with Linux occasionally I have been frustrated by the vast amount of conflicting information thrown up by a google search on a problem... I understand the difficulty of trying to support older and slower systems while keeping up with the newer processors and subsystems - I guess that since there is a finite number of developers some things will fall by the wayside due to difficulty or lack of interest. A fork would probably kill the project completely. It may be that in the end some platforms may be unsupportable due to limitations of the newer versions of GCC and the issue that keeping and maintaining older versions of GCC may be unworkable. I There is already a tier system for different architectures so maybe that should be extended to cover some of the more esoteric systems like arcnet. From my point of view I am really impressed by the progress on the ARM front and the integration of the DRM stuff for video support. Just need a few improvements to the USB system... One concern I do have is the linuxification of a lot of big applications - the likes on KDE etc. These seem to be heading down the road of being strongly dependant on kludges like systemd. I despair that these will kill off the ability to use NetBSD as a desktop system unless a suitable shim layer can
Re: Removing ARCNET stuffs
On 2015-05-30 21:37, David Holland wrote: On Fri, May 29, 2015 at 12:49:18PM +0200, Gert Doering wrote: > On Fri, May 29, 2015 at 10:22:35AM +, David Holland wrote: > > Because of these trends, I've been thinking for a while now that maybe > > it's getting to be time to fork. That would allow having one project > > that intends to stay current, with all the attendant requirements, > > which probably mostly doesn't make sense on vintage hardware; and > > another project that explicitly abandons most or all of that and > > instead concentrates on being the best possible traditional multiuser > > or workstation Unix, which does make sense on vintage hardware that > > was designed for (or could be adapted to) those roles, and which also > > makes sense on newer hardware to the extent it's consistent with the > > traditional role. > > I would argue that this has happened already - FreeBSD and NetBSD are > the results... at least from the outside, this is how it looks like, > with FreeBSD focusing on few platforms but modernizing itself quite > a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs > everywhere". Yes, see, this is the problem. "It runs everywhere" now means "it is an OS for junkyard machines". That was never the intent when that was NetBSD's market positioning, 15+ years ago. Nor is it the reality now. We have different views here. In my eyes, these "junkyard" machines have forced NetBSD to keep somewhat honest. The gradual dropping of "old" stuff means that in my eyes, things are going downhill towards more sloppy code and implementations, and more waste in general. So in my eyes, the "runs everywhere" is what have made NetBSD attractive at all, for all platforms, including modern ones. If you drop that, then NetBSD really becomes just yet another Unix clone, for which there is no real reason for it to exist at all. There are plenty of other alternatives in that niche, that have a much larger following. NetBSD will totally fail if they decide that this is where it should be going. > I'm not sure the BSD worlds needs yet another fork. No, it doesn't. On the other hand, running the same OS on 32-way x86_64 and Sparc IPC is increasingly not feasible or sensible. I don't follow you here. So what are you saying. That people who want to run some more modern software on old hardware should just go away? Or just throw away the old hardware and get some x86_64, and still continue to run NetBSD? What about people who actually enjoy running odd hardware? What are the options? From your arguing, I would say that the logical conclusion is that we *need* a fork, since you obviously are saying that supporting old hardware is not in the interest of NetBSD anymore. Now, a fork for people having old hardware don't have to originate from NetBSD, or from NetBSD-current. But in some ways it probably makes most sense to start from some point in NetBSD. > Now, speaking as application developer: I'd hate to see yet another BSD > fork that I have to test OpenVPN on regularily, to see whether "we" or > "they" broke something and system-specific parts need to be adjusted... > (right now, we build and test on FreeBSD, NetBSD and OpenBSD, and > various versions of those - sufficiently subtly different that there > has to be system-specific code for ifconfig/route handling...) Dragonfly? What about all the OpenBSD offshoots? Application developers of current software still have issues, and I guess the only solution is to actually start decreasing the number of supported OSes, and start with the ones that the fewest people use. I wish OSes could be more coherent in their APIs, and even have binary compatibility done better, but I guess I'm not going to solve that one. And remember - these are just my personal reflections and opinions. I'm sure a lot of people will disagree with me. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing ARCNET stuffs
On Fri, May 29, 2015 at 12:49:18PM +0200, Gert Doering wrote: > On Fri, May 29, 2015 at 10:22:35AM +, David Holland wrote: > > Because of these trends, I've been thinking for a while now that maybe > > it's getting to be time to fork. That would allow having one project > > that intends to stay current, with all the attendant requirements, > > which probably mostly doesn't make sense on vintage hardware; and > > another project that explicitly abandons most or all of that and > > instead concentrates on being the best possible traditional multiuser > > or workstation Unix, which does make sense on vintage hardware that > > was designed for (or could be adapted to) those roles, and which also > > makes sense on newer hardware to the extent it's consistent with the > > traditional role. > > I would argue that this has happened already - FreeBSD and NetBSD are > the results... at least from the outside, this is how it looks like, > with FreeBSD focusing on few platforms but modernizing itself quite > a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs > everywhere". Yes, see, this is the problem. "It runs everywhere" now means "it is an OS for junkyard machines". That was never the intent when that was NetBSD's market positioning, 15+ years ago. Nor is it the reality now. > I'm not sure the BSD worlds needs yet another fork. No, it doesn't. On the other hand, running the same OS on 32-way x86_64 and Sparc IPC is increasingly not feasible or sensible. > Now, speaking as application developer: I'd hate to see yet another BSD > fork that I have to test OpenVPN on regularily, to see whether "we" or > "they" broke something and system-specific parts need to be adjusted... > (right now, we build and test on FreeBSD, NetBSD and OpenBSD, and > various versions of those - sufficiently subtly different that there > has to be system-specific code for ifconfig/route handling...) Dragonfly? What about all the OpenBSD offshoots? -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On 2015-05-30 00:13, Matt Thomas wrote: On May 29, 2015, at 1:31 PM, paul_kon...@dell.com wrote: No, transfering a whole file is a single stream of stuff; reading individual records is a more complex handshake. And apart from that, things get significantly simpler if you only support Sequential files. Simpler still if you limit it to just two cases: fixed:512, and stream. Alas, that means most text files on VMS won’t be transferred since they are record based. Same story with RSX, and even more so. And not just text files. Can you get EDT or TPU to emit stream files? Not in RSX, you can't... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing ARCNET stuffs
> On May 29, 2015, at 1:31 PM, paul_kon...@dell.com wrote: > > No, transfering a whole file is a single stream of stuff; reading individual > records is a more complex handshake. And apart from that, things get > significantly simpler if you only support Sequential files. Simpler still if > you limit it to just two cases: fixed:512, and stream. Alas, that means most text files on VMS won’t be transferred since they are record based. Can you get EDT or TPU to emit stream files?
Re: Removing ARCNET stuffs
Johnny Billquist > On 2015-05-28 21:19, Tom Ivar Helbekkmo wrote: > > paul_kon...@dell.com writes: > > > >> And DECnet nodes exist around the Internet; the “Hobbyist DECnet” > >> group (“hecnet”) is the main focus of that activity as far as I know. > > > > ...and while I'm sure Johnny Billquist can supply more details, and > > correct me if I'm wrong, DECnet on NetBSD seems to me to be an active > > component of the hecnet environment. > > Nope. NetBSD do not run DECnet. I run a bridge program, which I > initially developed on NetBSD, but it runs on pretty much anything. > > I also hack NetBSD/VAX on and off, but it's becoming more and more "off" > with every new development within NetBSD. But that's a different story. > > Oh, and DECnet on Linux is not so great either, and I believe it has > been dropped from the main tree. > But if anyone wants to try and get NetBSD to talk DECnet, Paul and me > can certainly help in many ways. > I expressed my concerns regarding DECNet removal to Ryota in a private mail. I regret that I don't have enough resources to keep this code in the repos.
Re: Removing ARCNET stuffs
> On May 29, 2015, at 2:20 PM, Johnny Billquist wrote: > > On 2015-05-29 16:35, paul_kon...@dell.com wrote: >> >>> ... >>> DAP would be really nice, but it's complex. But I like the capabilities. >> >> I wouldn’t have thought of DAP as all that complex; after all it fits in >> PDP11 systems. You can probably subset it pretty nicely if you don’t need >> all the features. Just file transfer, as opposed to transparent file I/O, >> is likely to simplify things substantially. The DECnet/Linux implementation >> of DAP does this, I believe, and it does a reasonably good job. I think I >> even got it to talk successfully to a RSTS/E system at one time. > > I've never managed to get DAP under Linux to talk with an RSX node... > And I don't think you can subset it much. Depending on the remote machine, > different parts will be exercised. But I guess things like indexing file > access could be left out. But it's still rather more complex than anything > I've seen under Unix. But possibly various remote db protocols would be > similar. > > File transfer and file access in DAP is the same thing, I believe. Or maybe > you mean this in some way I'm missing. No, transfering a whole file is a single stream of stuff; reading individual records is a more complex handshake. And apart from that, things get significantly simpler if you only support Sequential files. Simpler still if you limit it to just two cases: fixed:512, and stream. paul
Re: Removing ARCNET stuffs
At date and time Fri, 29 May 2015 11:09:08 -0500, J. Lewis Muir wrote: > On 5/29/15 5:22 AM, David Holland wrote: > > Because of these trends, I've been thinking for a while now that maybe > > it's getting to be time to fork. > > Hello, David! > > I started using NetBSD because of its small base system disk and memory > footprint, focus on security, support for many machine architectures, > ability to scale well to large SMP machines, support for a wide range > of deployments from embedded to server to desktop (it's a big time > savings to only have to learn and remember how to do something on one > OS instead of many), and genteel user and developer community. I value > all of these things. (Some benefits I came to appreciate later were its > relatively long support for a release and its package management system, > pkgsrc (writing a package once and having it work on all platforms I use > is a big win).) [...] I sometimes think developers get so close they can't see the wood for the trees. They see all the flaws but fail to see the overall picture. As someone who struggles to understand code I am happily oblivious of NetBSD's flaws. What I can say, however, is that using NetBSD is so much more pleasant than using any of the modern Linux distributions, with the honourable exception of Crux and Slackware. I tried the latest Debian and CentOS recently and I wanted to throw up. Talk about over-engineering, deliberate obfuscation and condescension! It would be a tragedy of immense proportions to see NetBSD's small developer pool split up to pursue their own interests in yet another BSD fork. They have put together a first-rate, unequalled operating system that really is a pleasure to use. I for one didn't need marketing in order to find NetBSD; the sheer stupidity of other open-source operating systems was enough to drive me here. Why the need for marketing? We are intelligent enough to discover NetBSD for ourselves without marketing. If it does what we want then we stay with it. Simple. Is it really worth it putting the future of the project at risk over these small quarrels that pop up every now and again? Perhaps Ryota Ozaki could quantify the cost of maintaining this code? If it appears too costly then should we really go all out to maintain it, given what Ryota is offering in its stead - a multiprocessor-friendly network stack? Surely the pros have to be weighed up here, as well as the cons? Just my tuppence worth. NetBSD is to my mind nearly perfect. Adding a modern network stack, a modern filesystem and perhaps some MAC implementation (or do we already have that?) would make it unequalled. If we need to sacrifice some code along the way shouldn't we be prepared to do so? People will naturally gravitate towards excellence if it is provided, no marketing required. Let's keep the developer pool together, and let's not get all worked up over code if Ryota feels a multiprocessor network stack can't be easily achieved while it's in place. The pursuit of excellence is not always immediately rewarding, and some people stand to lose out for the greater good. That's life. No need for drama; let's make a mature decision about this and be grateful we still have NetBSD to work and play with, because, for me at least, 95% of the alternatives are rapidly heading for the gutter. -- Gerard Lally
Re: Removing ARCNET stuffs
On 2015-05-29 16:35, paul_kon...@dell.com wrote: On May 29, 2015, at 6:22 AM, Johnny Billquist wrote: On 2015-05-29 08:18, Matt Thomas wrote: ... I have a Phase IV+ (so I didn’t have to much with the physical address) implementation but never got around to writing the apps. socket interface is identical to DECnet-ULTRIX. DAP is a beast as is CTERM. I could run IP protocols over, but then I have IP for that. :) If you say that you didn't fiddle with physical addresses, then you have been playing Phase V, as Phase IV requires that you manipulate the physical address. And that is also true of IV+. Maybe Matt meant IV-prime? That’s an obscure variant of Phase IV invented to allow DECnet to run on 802.5 networks. I recently found a spec for it. It isn’t all that hard; the changes are just in the routing layer. And yes, it allows you to keep your physical address, so long as all the neighbors you need to talk to also run IV-prime. I remember seeing some note about an update to Phase IV to allow communication over 802.5 that would allow the interface to not have DECnet-specific addresses, but I haven't actually seen any implementation. But you could be right in that this is what Matt meant. Of course, if you have a LAN driver and interface that supports multiple individual addresses, you can use the HIORD style address for DECnet while keeping the conventional physical address for other protocols. Most hardware supports this, actually, though it’s not clear how many drivers do. DAP would be really nice, but it's complex. But I like the capabilities. I wouldn’t have thought of DAP as all that complex; after all it fits in PDP11 systems. You can probably subset it pretty nicely if you don’t need all the features. Just file transfer, as opposed to transparent file I/O, is likely to simplify things substantially. The DECnet/Linux implementation of DAP does this, I believe, and it does a reasonably good job. I think I even got it to talk successfully to a RSTS/E system at one time. I've never managed to get DAP under Linux to talk with an RSX node... And I don't think you can subset it much. Depending on the remote machine, different parts will be exercised. But I guess things like indexing file access could be left out. But it's still rather more complex than anything I've seen under Unix. But possibly various remote db protocols would be similar. File transfer and file access in DAP is the same thing, I believe. Or maybe you mean this in some way I'm missing. Johnny
Re: Removing ARCNET stuffs
> On May 29, 2015, at 6:22 AM, Johnny Billquist wrote: > > On 2015-05-29 08:18, Matt Thomas wrote: >> ... >> >> I have a Phase IV+ (so I didn’t have to much with the physical address) >> implementation but never got around to writing the apps. socket interface >> is identical to DECnet-ULTRIX. DAP is a beast as is CTERM. I could run IP >> protocols over, but then I have IP for that. :) > > If you say that you didn't fiddle with physical addresses, then you have been > playing Phase V, as Phase IV requires that you manipulate the physical > address. And that is also true of IV+. Maybe Matt meant IV-prime? That’s an obscure variant of Phase IV invented to allow DECnet to run on 802.5 networks. I recently found a spec for it. It isn’t all that hard; the changes are just in the routing layer. And yes, it allows you to keep your physical address, so long as all the neighbors you need to talk to also run IV-prime. Of course, if you have a LAN driver and interface that supports multiple individual addresses, you can use the HIORD style address for DECnet while keeping the conventional physical address for other protocols. Most hardware supports this, actually, though it’s not clear how many drivers do. > > DAP would be really nice, but it's complex. But I like the capabilities. I wouldn’t have thought of DAP as all that complex; after all it fits in PDP11 systems. You can probably subset it pretty nicely if you don’t need all the features. Just file transfer, as opposed to transparent file I/O, is likely to simplify things substantially. The DECnet/Linux implementation of DAP does this, I believe, and it does a reasonably good job. I think I even got it to talk successfully to a RSTS/E system at one time. paul
Re: Removing ARCNET stuffs
On 5/29/15 5:22 AM, David Holland wrote: > Because of these trends, I've been thinking for a while now that maybe > it's getting to be time to fork. Hello, David! I started using NetBSD because of its small base system disk and memory footprint, focus on security, support for many machine architectures, ability to scale well to large SMP machines, support for a wide range of deployments from embedded to server to desktop (it's a big time savings to only have to learn and remember how to do something on one OS instead of many), and genteel user and developer community. I value all of these things. (Some benefits I came to appreciate later were its relatively long support for a release and its package management system, pkgsrc (writing a package once and having it work on all platforms I use is a big win).) Personally, I don't have an interest in running NetBSD on vintage hardware. However, I understand and respect that some people do, and I have nothing against that. I would very much so hope for NetBSD to *not* fork! I agree with Taylor Campbell: "I suspect if people have the time and energy to make and maintain a fork, they certainly have the time to write automatic tests for the old network protocols." [1] In "Evolving Frameworks," [2] Don Roberts and Ralph Johnson suggest in the "Tree Examples" pattern that you should never write a software framework unless you have at least three applications that use it. Part of the reasoning is that these applications help you come up with the proper abstractions for the framework. If you think of NetBSD as a framework and the machine architectures and hardware as applications, then perhaps all of those "applications" can actually be a benefit to NetBSD and help it to have really nice abstractions and design. Of course, bit rot is bad, and I can certainly understand those who would like to remove things that aren't used. It's more work to maintain those things, and, in some cases, it offers a bigger attack surface to attackers. I understand the argument that something can always be restored from the attic if someone wants it, but the downside of that is that, while NetBSD advances, deleted things remain as they were when deleted and thus become more difficult to bring back over time. But if you have automatic tests as Taylor Campbell suggested, those things could potentially stay in the tree, and changes can be made to them with some level of confidence because the automatic tests still pass. Regards, Lewis [1] http://mail-index.netbsd.org/tech-kern/2015/05/29/msg018796.html [2] http://st-www.cs.illinois.edu/users/droberts/evolve.html
Re: Removing ARCNET stuffs
On 28 May, 2015, at 17:57 , Tyler Retzlaff wrote: > On 5/28/2015 12:39 PM, Robert Swindells wrote: >> Radoslaw Kujawa wrote: >> >> The same arguments might be made against the plan to remove ATM >> support. > > I've got no problem with keeping it, removing it isn't really intellectually > rewarding I thought it more of a cleanup/chore that nobody really wanted to > do. I only suggested removal because I know the code is broken. > > I guess we could at least make it compile again if we kept it and add it to > the ALL kernels. Is that enough? It's likely to still be broken and > difficult to efficiently fix without any hardware though. A long time ago I wrote code to support ATM interfaces for routers that had the hardware. I'm pretty sure they sold quite a few of those interfaces and were still selling them not that long ago; ADSL uses ATM framing and some carriers had ATM networks for backhaul until they could no longer afford to pay the switch vendors to maintain them. I think you would say those routers supported ATM, and I don't recall any complaints about that support being incomplete in some way, yet that code did nothing similar to the stuff in sys/netnatm. I know of no application which requires that and it clearly isn't necessary to do something useful with ATM interfaces that people were willing to spend (not inconsiderable) money for without it. I would be much more impressed if someone stepped up, said they knew what that code did and described what they would use it for if the code actually worked. As it is I believe that code not only doesn't work but would have no utility if it did and probably wasn't a good idea even when it was first included in the kernel and you could still buy the hardware. If someone had ATM hardware they wanted to support they still wouldn't need that code and would probably be better off if it were absent so they wouldn't think the driver should be dependent on it. If the idea of removing this causes angst I can't see how anything can be removed, ever. Dennis Ferguson
Re: Removing ARCNET stuffs
Date: Fri, 29 May 2015 10:22:35 + From: David Holland Because of these trends, I've been thinking for a while now that maybe it's getting to be time to fork. That would allow having one project that intends to stay current, with all the attendant requirements, which probably mostly doesn't make sense on vintage hardware; and another project that explicitly abandons most or all of that and instead concentrates on being the best possible traditional multiuser or workstation Unix, which does make sense on vintage hardware that was designed for (or could be adapted to) those roles, and which also makes sense on newer hardware to the extent it's consistent with the traditional role. I suspect if people have the time and energy to make and maintain a fork, they certainly have the time to write automatic tests for the old network protocols. If anyone wants to sit down and do that, I would be happy to help. If not, there already are `forks' that work: netbsd-5, netbsd-4, &c.
Re: Removing ARCNET stuffs
David Holland wrote: >On Thu, May 28, 2015 at 08:06:56PM +0200, Tom Ivar Helbekkmo wrote: > > Me, too. What NetBSD offers, that no other O/S offers, is the support > > for platforms that are no longer mainstream. I've run it on Sparc and > > VAX processors for years, and hope to continue playing with these old > > machines. I enjoy reading about others running NetBSD on even more > > exotic platforms. (Incidentally, and I run OmniNet (an ancient 2Mbps > > token ring network) between machines in my home lab that are too old to > > even run NetBSD.) > >I don't think (in general) that removing things is a good idea; but >it's increasingly difficult to keep NetBSD running on ancient >hardware. It's already infeasible to run the system compiler on most >such machines; this is only going to get worse with time. Other bloat >accumulates too, less rapidly perhaps but still so. The other day I >observed in chat that Someone(TM) needs to sit down with a slow >machine and a profiler for a while and find and kill all the >gratuitous bubble sorts, linear searches, and other things that run >too fast to be noticed on modern h/w; nobody disagreed, but on the >other hand nobody's been rushing to do it either. And other things >necessary for remaining relevant to semi-current hardware and usage, >like keeping up with X, desktop, and virtualization things, are often >in direct conflict with maintaining support for old hardware. I tried booting -current on a mac68k earlier this week, it certainly felt slower than I remembered. [snip] >Because of these trends, I've been thinking for a while now that maybe >it's getting to be time to fork. That would allow having one project >that intends to stay current, with all the attendant requirements, >which probably mostly doesn't make sense on vintage hardware; and >another project that explicitly abandons most or all of that and >instead concentrates on being the best possible traditional multiuser >or workstation Unix, which does make sense on vintage hardware that >was designed for (or could be adapted to) those roles, and which also >makes sense on newer hardware to the extent it's consistent with the >traditional role. I started using NetBSD because I wanted to use it on embedded systems. Being able to use exactly the same OS on a desktop machine for development was a big help and something that you don't really get with Linux as there are so many different source trees. Robert Swindells
Re: Removing ARCNET stuffs
Hi, On Fri, May 29, 2015 at 10:22:35AM +, David Holland wrote: > Because of these trends, I've been thinking for a while now that maybe > it's getting to be time to fork. That would allow having one project > that intends to stay current, with all the attendant requirements, > which probably mostly doesn't make sense on vintage hardware; and > another project that explicitly abandons most or all of that and > instead concentrates on being the best possible traditional multiuser > or workstation Unix, which does make sense on vintage hardware that > was designed for (or could be adapted to) those roles, and which also > makes sense on newer hardware to the extent it's consistent with the > traditional role. I would argue that this has happened already - FreeBSD and NetBSD are the results... at least from the outside, this is how it looks like, with FreeBSD focusing on few platforms but modernizing itself quite a bit (kernel preempting, zfs, ...) and NetBSD focusing on "it runs everywhere". I'm not sure the BSD worlds needs yet another fork. Now, speaking as application developer: I'd hate to see yet another BSD fork that I have to test OpenVPN on regularily, to see whether "we" or "they" broke something and system-specific parts need to be adjusted... (right now, we build and test on FreeBSD, NetBSD and OpenBSD, and various versions of those - sufficiently subtly different that there has to be system-specific code for ifconfig/route handling...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de
Re: Removing ARCNET stuffs
On Thu, May 28, 2015 at 05:01:02PM +, paul_kon...@dell.com wrote: > > But I too find it regrettable and possibly dangerous. One of my > > copious-spare-time projects is to dig up enough specs to add a DECnet > > stack to my systems; > > DECnet phase IV specs are readily available and good enough to > build interoperable implementations (which isn?t true, > unfortunately, for a lot of protocol specs). DECnet Phase IV > (DECnet/OSI) specs also have been uncovered, though they are in > more obscure spots. And DECnet nodes exist around the Internet; > the ?Hobbyist DECnet? group (?hecnet?) is the main focus of that > activity as far as I know. > > If you want pointers to documents, just ask, I can supply those. slightly relatedly, do you (or anyone else reading this) happen to know what happened to the mopd patches described in PR 3344? -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
On 2015-05-29 08:18, Matt Thomas wrote: On May 28, 2015, at 4:15 PM, Johnny Billquist wrote: On 2015-05-28 21:19, Tom Ivar Helbekkmo wrote: paul_kon...@dell.com writes: And DECnet nodes exist around the Internet; the “Hobbyist DECnet” group (“hecnet”) is the main focus of that activity as far as I know. ...and while I'm sure Johnny Billquist can supply more details, and correct me if I'm wrong, DECnet on NetBSD seems to me to be an active component of the hecnet environment. Nope. NetBSD do not run DECnet. I run a bridge program, which I initially developed on NetBSD, but it runs on pretty much anything. Your’s don’t. :) If it doesn't, then I should fix it. Currently I'm just running it under Linux and OSX, and I know others who have run it on Windows and OpenBSD. I haven't tested on NetBSD recently, but if there is some problem it should be really easy to fix. That said, the code is just a plan, ugly hack. Oh, and DECnet on Linux is not so great either, and I believe it has been dropped from the main tree. But if anyone wants to try and get NetBSD to talk DECnet, Paul and me can certainly help in many ways. I have a Phase IV+ (so I didn’t have to much with the physical address) implementation but never got around to writing the apps. socket interface is identical to DECnet-ULTRIX. DAP is a beast as is CTERM. I could run IP protocols over, but then I have IP for that. :) If you say that you didn't fiddle with physical addresses, then you have been playing Phase V, as Phase IV requires that you manipulate the physical address. And that is also true of IV+. DAP would be really nice, but it's complex. But I like the capabilities. CTERM on the other hand is on my top-3 list of things I hate (pretty much the norm for all non-VMS people :-) ). I never committed it because I doubted there was interest. It’s probably bit rotted but I could resurrect it. Well, me for one would be interested... In a world a long time ago I was one of the kernel engineers for DECnet for ULTRIX and OSF/1 (nee Digital UNIX). It was one reason I could stand the netiso code because it was so horrible. Hey, cool. Then you should know more about this than I do. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing ARCNET stuffs
On Thu, May 28, 2015 at 08:06:56PM +0200, Tom Ivar Helbekkmo wrote: > Me, too. What NetBSD offers, that no other O/S offers, is the support > for platforms that are no longer mainstream. I've run it on Sparc and > VAX processors for years, and hope to continue playing with these old > machines. I enjoy reading about others running NetBSD on even more > exotic platforms. (Incidentally, and I run OmniNet (an ancient 2Mbps > token ring network) between machines in my home lab that are too old to > even run NetBSD.) I don't think (in general) that removing things is a good idea; but it's increasingly difficult to keep NetBSD running on ancient hardware. It's already infeasible to run the system compiler on most such machines; this is only going to get worse with time. Other bloat accumulates too, less rapidly perhaps but still so. The other day I observed in chat that Someone(TM) needs to sit down with a slow machine and a profiler for a while and find and kill all the gratuitous bubble sorts, linear searches, and other things that run too fast to be noticed on modern h/w; nobody disagreed, but on the other hand nobody's been rushing to do it either. And other things necessary for remaining relevant to semi-current hardware and usage, like keeping up with X, desktop, and virtualization things, are often in direct conflict with maintaining support for old hardware. Meanwhile NetBSD has a persistent problem with marketing and market positioning; to wit, we don't seem able to market and we haven't been able to formulate any notion of who to market to or for what, or why anyone should want to use NetBSD. The result of this is that the 15+-year-old market positioning of "of course it runs NetBSD" is still floating around, except it's mutated into "NetBSD is an OS for junkyard hardware". And the problem with that -- no matter how much some people enjoy working with vintage hardware -- is that it doesn't attract very many users or developers; especially since, as already noted, NetBSD is not actually a very good OS for vintage hardware. On top of this, it doesn't seem to me that there's much space in the current and near-future computing landscape for traditional Unix; the department login machine model is dead, and only a handful of oldtimers use anything that can reasonably be described as a "workstation". Meanwhile, the "desktop" software for Unix is basically warmed-over Windows NT squatting on top of (not even integrated with) a base Unix; and the way server farms are going there's increasingly little role for multiuser OSes at all. An OS project that wants to remain current has to adapt to these trends, and that means system- level and design changes that move away from the traditional multiuser Unix model that many of us are attached to. (This does not mean rushing to embrace systemd -- it means things like hotplug disks, numa-aware scheduling, filesystems for SSDs, streamlined system configuration, and different security models; it also means keeping up with moving standards like C++ and 802.11, and staying up to date with necessary 3rd party software like gcc and X11.) Because of these trends, I've been thinking for a while now that maybe it's getting to be time to fork. That would allow having one project that intends to stay current, with all the attendant requirements, which probably mostly doesn't make sense on vintage hardware; and another project that explicitly abandons most or all of that and instead concentrates on being the best possible traditional multiuser or workstation Unix, which does make sense on vintage hardware that was designed for (or could be adapted to) those roles, and which also makes sense on newer hardware to the extent it's consistent with the traditional role. At the moment NetBSD is trying to span both of these goal sets, leaning somewhat towards the latter through conservatism, and not doing either very well. I'm not at all sure that forking will improve the situation (or that forking per se is even necessary to handle both these foci) but it's probably at least worth thinking about. (I am not sure, if this fork happened, which project I'd work on; probably both.) There's one other thing I ought to mention here, which is that I have never entirely understood the point of running a modern OS on old hardware; if you're going to run a modern OS, you can run it on modern hardware and you get the exact same things as on old hardware, except faster and smoother. It's always seemed to me that running vintage OSes (on old hardware or even new) is more interesting, because that way you get a complete vintage environment with its own, substantively different, set of things. This does require maintaining the vintage OSes, but that's part of the fun... nonetheless, because I don't understand this point I may be suggesting something that makes no sense to people who do, so take all the above with that grain of salt. -- David A. Holland dholl...@netbsd.org
Re: Removing ARCNET stuffs
> On May 28, 2015, at 4:15 PM, Johnny Billquist wrote: > > On 2015-05-28 21:19, Tom Ivar Helbekkmo wrote: >> paul_kon...@dell.com writes: >> >>> And DECnet nodes exist around the Internet; the “Hobbyist DECnet” >>> group (“hecnet”) is the main focus of that activity as far as I know. >> >> ...and while I'm sure Johnny Billquist can supply more details, and >> correct me if I'm wrong, DECnet on NetBSD seems to me to be an active >> component of the hecnet environment. > > Nope. NetBSD do not run DECnet. I run a bridge program, which I initially > developed on NetBSD, but it runs on pretty much anything. Your’s don’t. :) > I also hack NetBSD/VAX on and off, but it's becoming more and more "off" with > every new development within NetBSD. But that's a different story. Sigh. > Oh, and DECnet on Linux is not so great either, and I believe it has been > dropped from the main tree. > But if anyone wants to try and get NetBSD to talk DECnet, Paul and me can > certainly help in many ways. I have a Phase IV+ (so I didn’t have to much with the physical address) implementation but never got around to writing the apps. socket interface is identical to DECnet-ULTRIX. DAP is a beast as is CTERM. I could run IP protocols over, but then I have IP for that. :) I never committed it because I doubted there was interest. It’s probably bit rotted but I could resurrect it. In a world a long time ago I was one of the kernel engineers for DECnet for ULTRIX and OSF/1 (nee Digital UNIX). It was one reason I could stand the netiso code because it was so horrible.
Re: Removing ARCNET stuffs
On 5/28/2015 12:39 PM, Robert Swindells wrote: Radoslaw Kujawa wrote: The same arguments might be made against the plan to remove ATM support. I've got no problem with keeping it, removing it isn't really intellectually rewarding I thought it more of a cleanup/chore that nobody really wanted to do. I only suggested removal because I know the code is broken. I guess we could at least make it compile again if we kept it and add it to the ALL kernels. Is that enough? It's likely to still be broken and difficult to efficiently fix without any hardware though. I admit if I had en(4) hardware to test with I would have spent the time. Maybe someone has this hardware? rtr
Re: Removing ARCNET stuffs
On 2015-05-28 21:19, Tom Ivar Helbekkmo wrote: paul_kon...@dell.com writes: And DECnet nodes exist around the Internet; the “Hobbyist DECnet” group (“hecnet”) is the main focus of that activity as far as I know. ...and while I'm sure Johnny Billquist can supply more details, and correct me if I'm wrong, DECnet on NetBSD seems to me to be an active component of the hecnet environment. Nope. NetBSD do not run DECnet. I run a bridge program, which I initially developed on NetBSD, but it runs on pretty much anything. I also hack NetBSD/VAX on and off, but it's becoming more and more "off" with every new development within NetBSD. But that's a different story. Oh, and DECnet on Linux is not so great either, and I believe it has been dropped from the main tree. But if anyone wants to try and get NetBSD to talk DECnet, Paul and me can certainly help in many ways. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Removing ARCNET stuffs
On Fri, May 29, 2015 at 1:53 AM, Taylor R Campbell wrote: >Date: Thu, 28 May 2015 17:39:12 +0100 (BST) >From: Robert Swindells > >>Support for several legacy protocols was removed in recent years. I >>fear that our networking stack is becoming more and more IP and >>Ethernet centric. > >It isn't as bad as the Linux stack yet but I would also like to see a >variety of protocols in the tree. Even if they don't always work I >have found it useful to be able to look at other ways of doing stuff. > >I have been doing a bit of work on cleaning up some old Chaosnet and >CAN code recently. > > Diversity is great, but only if it is exercised. It would be > worthwhile if someone with knowledge of these protocols could make > automatic tests with rump that everyone can run, without needing > hardware. See, e.g., shmif(4) for ethernet in rump. That's a good idea. We would be able to live with arcnet if there are such tests. Any contributions are welcome from arcnet/amiga lovers or someone else :) ozaki-r
Re: Removing ARCNET stuffs
Taylor R Campbell writes: > Diversity is great, but only if it is exercised. Yeah, but some of the old stuff is always going to be used off and on, as people with an interest in the particular technology come and go. Ditching support for something the moment no-one is actively using it, thus denying new arrivals the chance to use it, is not a good idea. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
Re: Removing ARCNET stuffs
mo...@rodents-montreal.org writes: > But I too find it regrettable and possibly dangerous. Me, too. What NetBSD offers, that no other O/S offers, is the support for platforms that are no longer mainstream. I've run it on Sparc and VAX processors for years, and hope to continue playing with these old machines. I enjoy reading about others running NetBSD on even more exotic platforms. (Incidentally, and I run OmniNet (an ancient 2Mbps token ring network) between machines in my home lab that are too old to even run NetBSD.) If support for network protocols belonging to platforms still supported by NetBSD itself is going to be ditched, that's a very sad development, and a step in the direction of saying "forget NetBSD - let's all just run FreeBSD (or even Linux) on iAPX64 platforms instead". -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
Re: Removing ARCNET stuffs
paul_kon...@dell.com writes: > And DECnet nodes exist around the Internet; the “Hobbyist DECnet” > group (“hecnet”) is the main focus of that activity as far as I know. ...and while I'm sure Johnny Billquist can supply more details, and correct me if I'm wrong, DECnet on NetBSD seems to me to be an active component of the hecnet environment. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
Re: Removing ARCNET stuffs
> On May 28, 2015, at 12:52 PM, Mouse wrote: > >> Support for several legacy protocols was removed in recent years. I fear tha$ > > To an extent that's inevitable, because so much of the networking world > in general is becoming IP- and Ethernet-centric. > > But I too find it regrettable and possibly dangerous. One of my > copious-spare-time projects is to dig up enough specs to add a DECnet > stack to my systems; DECnet phase IV specs are readily available and good enough to build interoperable implementations (which isn’t true, unfortunately, for a lot of protocol specs). DECnet Phase IV (DECnet/OSI) specs also have been uncovered, though they are in more obscure spots. And DECnet nodes exist around the Internet; the “Hobbyist DECnet” group (“hecnet”) is the main focus of that activity as far as I know. If you want pointers to documents, just ask, I can supply those. paul
Re: Removing ARCNET stuffs
On Thu, May 28, 2015 at 05:39:12PM +0100, Robert Swindells wrote: > [...] > I have been doing a bit of work on cleaning up some old Chaosnet and > CAN code recently. Do you have some CAN code available ? I'm interested (especially J1939) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Removing ARCNET stuffs
Date: Thu, 28 May 2015 17:39:12 +0100 (BST) From: Robert Swindells >Support for several legacy protocols was removed in recent years. I >fear that our networking stack is becoming more and more IP and >Ethernet centric. It isn't as bad as the Linux stack yet but I would also like to see a variety of protocols in the tree. Even if they don't always work I have found it useful to be able to look at other ways of doing stuff. I have been doing a bit of work on cleaning up some old Chaosnet and CAN code recently. Diversity is great, but only if it is exercised. It would be worthwhile if someone with knowledge of these protocols could make automatic tests with rump that everyone can run, without needing hardware. See, e.g., shmif(4) for ethernet in rump.
Re: Removing ARCNET stuffs
> Support for several legacy protocols was removed in recent years. I fear tha$ To an extent that's inevitable, because so much of the networking world in general is becoming IP- and Ethernet-centric. But I too find it regrettable and possibly dangerous. One of my copious-spare-time projects is to dig up enough specs to add a DECnet stack to my systems; based on my experience with DECnet under Ultrix, I think it would be a good test case for dealing with some of the IPisms. (It wouldn't help much with Ethernet; DECnet does support serial links, but NetBSD already has two network interfaces that support IP over serial links too.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Removing ARCNET stuffs
Radoslaw Kujawa wrote: >> On 28 May 2015, at 10:30, Ryota Ozaki wrote: >> >> On Thu, May 28, 2015 at 3:58 PM, Frank Wille wrote: >>> On Thu, 28 May 2015 11:57:11 +0900 >>> Ryota Ozaki wrote: >>> > As far as I can see Arcnet is only used by the Amiga bah(4) driver. > Isn't it possible to keep it somehow, as an MP-safe network stack would > be irrelevant for the Amiga platform? We could keep it with some pain, but we cannot keep it working if there is really no user. (I'm not sure if it works or not even now.) Is it still worthwhile? >>> >>> I will not insist in keeping it when there is pain to do so. And you may >>> be right that there is no user, but this is valid for a lot of platforms >>> and drivers. >>> >>> Anyway I don't proceed this attempt ignoring your request. I wish there were actual users though... >>> >>> Maybe we can wait for a few days to give more potential users the chance >>> to read these messages on the port-amiga list? >> >> Sure. I was a bit eager. >> >>> >>> In the meantime I will talk with other Amiga users if anybody owns such >>> a board. Probably is@ still got one, as he was working on the driver many >>> years ago. >> >> Thanks! >> >>> >>> When nothing happens and nobody is able to test it, we can remove the code. >> >> Okay, I'm waiting more. >There are companies still making PCI Express ARCnet interface cards, >hubs and converter devices: >http://www.ccontrols.com/arccontrol/nims.htm > >I'm not entirely sure that removing support for a standard that is >still actually used out in the world is a good idea. Maybe it is not >used much with NetBSD, since we only have amiga-specific driver. One >more downside, is that anything ARCnet related is rather expensive now >(around $400 for a single new PCI interface card). The same arguments might be made against the plan to remove ATM support. >I wish I had more free time... fixing ARCnet and implementing support >for newer interface cards seems like an interesting project. >Support for several legacy protocols was removed in recent years. I >fear that our networking stack is becoming more and more IP and >Ethernet centric. It isn't as bad as the Linux stack yet but I would also like to see a variety of protocols in the tree. Even if they don't always work I have found it useful to be able to look at other ways of doing stuff. I have been doing a bit of work on cleaning up some old Chaosnet and CAN code recently. Robert Swindells
Re: Removing ARCNET stuffs
> On 28 May 2015, at 10:30, Ryota Ozaki wrote: > > On Thu, May 28, 2015 at 3:58 PM, Frank Wille wrote: >> On Thu, 28 May 2015 11:57:11 +0900 >> Ryota Ozaki wrote: >> As far as I can see Arcnet is only used by the Amiga bah(4) driver. Isn't it possible to keep it somehow, as an MP-safe network stack would be irrelevant for the Amiga platform? >>> >>> We could keep it with some pain, but we cannot keep it working if there is >>> really no user. (I'm not sure if it works or not even now.) Is it still >>> worthwhile? >> >> I will not insist in keeping it when there is pain to do so. And you may >> be right that there is no user, but this is valid for a lot of platforms >> and drivers. >> >> >>> Anyway I don't proceed this attempt ignoring your request. >>> I wish there were actual users though... >> >> Maybe we can wait for a few days to give more potential users the chance >> to read these messages on the port-amiga list? > > Sure. I was a bit eager. > >> >> In the meantime I will talk with other Amiga users if anybody owns such >> a board. Probably is@ still got one, as he was working on the driver many >> years ago. > > Thanks! > >> >> When nothing happens and nobody is able to test it, we can remove the code. > > Okay, I'm waiting more. There are companies still making PCI Express ARCnet interface cards, hubs and converter devices: http://www.ccontrols.com/arccontrol/nims.htm I'm not entirely sure that removing support for a standard that is still actually used out in the world is a good idea. Maybe it is not used much with NetBSD, since we only have amiga-specific driver. One more downside, is that anything ARCnet related is rather expensive now (around $400 for a single new PCI interface card). I wish I had more free time... fixing ARCnet and implementing support for newer interface cards seems like an interesting project. Support for several legacy protocols was removed in recent years. I fear that our networking stack is becoming more and more IP and Ethernet centric. -- Best regards, Radoslaw Kujawa
Re: Removing ARCNET stuffs
On Thu, May 28, 2015 at 3:58 PM, Frank Wille wrote: > On Thu, 28 May 2015 11:57:11 +0900 > Ryota Ozaki wrote: > >> > As far as I can see Arcnet is only used by the Amiga bah(4) driver. >> > Isn't it possible to keep it somehow, as an MP-safe network stack would >> > be irrelevant for the Amiga platform? >> >> We could keep it with some pain, but we cannot keep it working if there is >> really no user. (I'm not sure if it works or not even now.) Is it still >> worthwhile? > > I will not insist in keeping it when there is pain to do so. And you may > be right that there is no user, but this is valid for a lot of platforms > and drivers. > > >> Anyway I don't proceed this attempt ignoring your request. >> I wish there were actual users though... > > Maybe we can wait for a few days to give more potential users the chance > to read these messages on the port-amiga list? Sure. I was a bit eager. > > In the meantime I will talk with other Amiga users if anybody owns such > a board. Probably is@ still got one, as he was working on the driver many > years ago. Thanks! > > When nothing happens and nobody is able to test it, we can remove the code. Okay, I'm waiting more. ozaki-r
Re: Removing ARCNET stuffs
On Thu, 28 May 2015 11:57:11 +0900 Ryota Ozaki wrote: > > As far as I can see Arcnet is only used by the Amiga bah(4) driver. > > Isn't it possible to keep it somehow, as an MP-safe network stack would > > be irrelevant for the Amiga platform? > > We could keep it with some pain, but we cannot keep it working if there is > really no user. (I'm not sure if it works or not even now.) Is it still > worthwhile? I will not insist in keeping it when there is pain to do so. And you may be right that there is no user, but this is valid for a lot of platforms and drivers. > Anyway I don't proceed this attempt ignoring your request. > I wish there were actual users though... Maybe we can wait for a few days to give more potential users the chance to read these messages on the port-amiga list? In the meantime I will talk with other Amiga users if anybody owns such a board. Probably is@ still got one, as he was working on the driver many years ago. When nothing happens and nobody is able to test it, we can remove the code. -- Frank Wille
Re: Removing ARCNET stuffs
On Wed, May 27, 2015 at 6:51 PM, Frank Wille wrote: > On Wed, 27 May 2015 18:18:06 +0900 > Ryota Ozaki wrote: > >> > What are the reasons behind removing working parts from the source tree >> > anyway? Aren't there more important things to do? >> >> We're working on making the network stack MP-safe and runnable in >> parallel. That requires an overhaul of the entire source tree. > > Ok. That might be important enough to sacrifice it, when there really > is no other option. > > As far as I can see Arcnet is only used by the Amiga bah(4) driver. > Isn't it possible to keep it somehow, as an MP-safe network stack would > be irrelevant for the Amiga platform? We could keep it with some pain, but we cannot keep it working if there is really no user. (I'm not sure if it works or not even now.) Is it still worthwhile? Anyway I don't proceed this attempt ignoring your request. I wish there were actual users though... ozaki-r
Re: Removing ARCNET stuffs
On Wed, 27 May 2015 18:18:06 +0900 Ryota Ozaki wrote: > > What are the reasons behind removing working parts from the source tree > > anyway? Aren't there more important things to do? > > We're working on making the network stack MP-safe and runnable in > parallel. That requires an overhaul of the entire source tree. Ok. That might be important enough to sacrifice it, when there really is no other option. As far as I can see Arcnet is only used by the Amiga bah(4) driver. Isn't it possible to keep it somehow, as an MP-safe network stack would be irrelevant for the Amiga platform? -- Frank Wille
Re: Removing ARCNET stuffs
On Wed, May 27, 2015 at 5:19 PM, Frank Wille wrote: > On Tue, 26 May 2015 16:20:09 +0900 > Ryota Ozaki wrote: > >> The next sacrifice is ARCNET. It seems it hasn't been >> used for long years (7 years or more): >> http://mail-index.netbsd.org/source-changes/2015/05/22/msg066175.html >> >> So I'm trying to remove them but the target files are >> much more than I had expected (see the bellow diffstat). >> >> Please stop me if you want to keep the files. > > I don't have an Arcnet board and I don't know anybody using it, but > on the Amiga there are not many options for network cards. If somebody > happens to own an Arcnet board he would be happy to use it. > > What are the reasons behind removing working parts from the source tree > anyway? Aren't there more important things to do? We're working on making the network stack MP-safe and runnable in parallel. That requires an overhaul of the entire source tree. So we're cleaning up and refactoring the code first to prepare later improvements. This attempt is a part of the goal. I'm trying this removal because I had doubt it's working and it's maintained by someone (see the above link). Please correct me if I'm wrong. And of course if there is anyone using it, I'm pleased to withdraw the proposal. ozaki-r
Re: Removing ARCNET stuffs
Am 26.05.15 um 09:20 schrieb Ryota Ozaki: > Hi, > > The next sacrifice is ARCNET. It seems it hasn't been > used for long years (7 years or more): > http://mail-index.netbsd.org/source-changes/2015/05/22/msg066175.html > > So I'm trying to remove them but the target files are > much more than I had expected (see the bellow diffstat). > > Please stop me if you want to keep the files. I think it also time to remove the starnet tty line discipline, or did anybody already remove it? > > > The patch is here: > http://www.netbsd.org/~ozaki-r/remove-arcnet.diff > > and diffstat is this: > $ diffstat remove-arcnet.diff > b/distrib/sets/lists/comp/mi|2 > b/sys/arch/amiga/conf/DRACO |4 > b/sys/arch/amiga/conf/GENERIC |3 > b/sys/arch/amiga/conf/GENERIC.in|3 > b/sys/arch/amiga/conf/INSTALL |3 > b/sys/arch/amiga/conf/MDINSTALL |3 > b/sys/arch/amiga/conf/files.amiga |4 > b/sys/arch/amigappc/conf/GENERIC|3 > b/sys/arch/amigappc/conf/NULL |3 > b/sys/arch/amigappc/conf/files.amigappc |4 > b/sys/conf/files|6 > b/sys/net/Makefile |2 > b/sys/net/bpf.c |7 > b/sys/netinet/if_arp.c | 34 - > b/sys/netinet6/in6.c|1 > b/sys/netinet6/in6_ifattach.c | 16 > b/sys/netinet6/nd6.c|8 > b/sys/netinet6/nd6_nbr.c|1 > sys/arch/amiga/dev/if_bah_zbus.c| 152 > sys/dev/ic/smc90cx6.c | 985 > > sys/dev/ic/smc90cx6reg.h| 80 -- > sys/dev/ic/smc90cx6var.h| 76 -- > sys/net/if_arc.h| 126 > sys/net/if_arcsubr.c| 662 - > 24 files changed, 2 insertions(+), 2186 deletions(-) > > > Thanks, > ozaki-r >
Re: Removing ARCNET stuffs
On Tue, 26 May 2015 16:20:09 +0900 Ryota Ozaki wrote: > The next sacrifice is ARCNET. It seems it hasn't been > used for long years (7 years or more): > http://mail-index.netbsd.org/source-changes/2015/05/22/msg066175.html > > So I'm trying to remove them but the target files are > much more than I had expected (see the bellow diffstat). > > Please stop me if you want to keep the files. I don't have an Arcnet board and I don't know anybody using it, but on the Amiga there are not many options for network cards. If somebody happens to own an Arcnet board he would be happy to use it. What are the reasons behind removing working parts from the source tree anyway? Aren't there more important things to do? -- Frank Wille
Re: Removing ARCNET stuffs
r...@netbsd.org (Tyler Retzlaff) writes: >i don't think it's fair to say something is being destroyed here. How would you express it, when someone removes code and refactors interfaces so that the code cannot possibly work anymore. Putting it on a graveyard? >if it's in use fine let's keep it. otherwise retiring the code is >favorable and not doing so is burdensome with respect to re-factoring >code that is in use. There is lots of code that I wouldn't consider to be in use, but the burden to maintain it has very little to do with looking at the additional codelines. In fact, that mostly helps to create more stable and versatile interfaces and abstractions. Talking other people into even considering code changes or, beware, testing them, that is a burden. And yes, just declaring things to be "dead code" is much easier. >if someone does decide later they want it then they can pull it out of >the attic and fix it up? Maybe they could import the Linux arcnet support then. Tracking upstream can be so creative. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Removing ARCNET stuffs
On Wed, May 27, 2015 at 8:38 AM, Tyler Retzlaff wrote: > > > On 5/26/2015 5:46 PM, Michael van Elst wrote: >> >> ozak...@netbsd.org (Ryota Ozaki) writes: >> >>> The next sacrifice is ARCNET. It seems it hasn't been >>> used for long years (7 years or more): >> >> >> I wish people would put more energy in creating things >> than destroying things they are not interested in. >> > > i don't think it's fair to say something is being destroyed here. > > if it's in use fine let's keep it. otherwise retiring the code is favorable > and not doing so is burdensome with respect to re-factoring code that is in > use. Yes. I believe the cleanups help later creative work. ozaki-r > > if someone does decide later they want it then they can pull it out of the > attic and fix it up? > > rtr
Re: Removing ARCNET stuffs
On 5/26/2015 5:46 PM, Michael van Elst wrote: ozak...@netbsd.org (Ryota Ozaki) writes: The next sacrifice is ARCNET. It seems it hasn't been used for long years (7 years or more): I wish people would put more energy in creating things than destroying things they are not interested in. i don't think it's fair to say something is being destroyed here. if it's in use fine let's keep it. otherwise retiring the code is favorable and not doing so is burdensome with respect to re-factoring code that is in use. if someone does decide later they want it then they can pull it out of the attic and fix it up? rtr
Re: Removing ARCNET stuffs
ozak...@netbsd.org (Ryota Ozaki) writes: >The next sacrifice is ARCNET. It seems it hasn't been >used for long years (7 years or more): I wish people would put more energy in creating things than destroying things they are not interested in. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Removing ARCNET stuffs
Hi, The next sacrifice is ARCNET. It seems it hasn't been used for long years (7 years or more): http://mail-index.netbsd.org/source-changes/2015/05/22/msg066175.html So I'm trying to remove them but the target files are much more than I had expected (see the bellow diffstat). Please stop me if you want to keep the files. The patch is here: http://www.netbsd.org/~ozaki-r/remove-arcnet.diff and diffstat is this: $ diffstat remove-arcnet.diff b/distrib/sets/lists/comp/mi|2 b/sys/arch/amiga/conf/DRACO |4 b/sys/arch/amiga/conf/GENERIC |3 b/sys/arch/amiga/conf/GENERIC.in|3 b/sys/arch/amiga/conf/INSTALL |3 b/sys/arch/amiga/conf/MDINSTALL |3 b/sys/arch/amiga/conf/files.amiga |4 b/sys/arch/amigappc/conf/GENERIC|3 b/sys/arch/amigappc/conf/NULL |3 b/sys/arch/amigappc/conf/files.amigappc |4 b/sys/conf/files|6 b/sys/net/Makefile |2 b/sys/net/bpf.c |7 b/sys/netinet/if_arp.c | 34 - b/sys/netinet6/in6.c|1 b/sys/netinet6/in6_ifattach.c | 16 b/sys/netinet6/nd6.c|8 b/sys/netinet6/nd6_nbr.c|1 sys/arch/amiga/dev/if_bah_zbus.c| 152 sys/dev/ic/smc90cx6.c | 985 sys/dev/ic/smc90cx6reg.h| 80 -- sys/dev/ic/smc90cx6var.h| 76 -- sys/net/if_arc.h| 126 sys/net/if_arcsubr.c| 662 - 24 files changed, 2 insertions(+), 2186 deletions(-) Thanks, ozaki-r
