Re: Removing ARCNET stuffs

[Marc Balmer]

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
>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

[Frank Wille]

On Wed, 27 May 2015 18:18:06 +0900
Ryota Ozaki <oza...@netbsd.org> 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

[Radoslaw Kujawa]

> On 28 May 2015, at 10:30, Ryota Ozaki <oza...@netbsd.org> wrote:
>
> On Thu, May 28, 2015 at 3:58 PM, Frank Wille <fr...@phoenix.owl.de> wrote:

>> On Thu, 28 May 2015 11:57:11 +0900
>> Ryota Ozaki <oza...@netbsd.org> 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

[Robert Swindells]

Radoslaw Kujawa <radosla...@c0ff33.net> wrote:
>> On 28 May 2015, at 10:30, Ryota Ozaki <oza...@netbsd.org> wrote:
>>
>> On Thu, May 28, 2015 at 3:58 PM, Frank Wille <fr...@phoenix.owl.de> wrote:

>>> On Thu, 28 May 2015 11:57:11 +0900
>>> Ryota Ozaki <oza...@netbsd.org> 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?
>>>>

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

[Taylor R Campbell]

Date: Thu, 28 May 2015 17:39:12 +0100 (BST)
From: Robert Swindells <r...@fdy2.co.uk>

>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.

[Manuel Bouyer]

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 <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--

[Tom Ivar Helbekkmo]

Taylor R Campbell <campbell+net...@mumble.net> 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"

[Ryota Ozaki]

On Fri, May 29, 2015 at 1:53 AM, Taylor R Campbell
<campbell+net...@mumble.net> wrote:
> Date: Thu, 28 May 2015 17:39:12 +0100 (BST)
> From: Robert Swindells <r...@fdy2.co.uk>
>

> >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

[Dennis Ferguson]

On 28 May, 2015, at 17:57 , Tyler Retzlaff <r...@omicron-persei-8.net> wrote:
> On 5/28/2015 12:39 PM, Robert Swindells wrote:

>> Radoslaw Kujawa <radosla...@c0ff33.net> 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