On Wed, 26 Apr 2000, Jens David wrote:

> please calm down and let us deal with this on the facts. It was definetely
> not my intention to start another flamewar when I did that announcement.

Neither did I. Sorry if I seemed a little too exited earlier.

> Fact is, nobody else but Jan and Joerg came up with any concrete, factual
> ideas/founded bug reports/patches. This is _very_ irritating, especially
> if you spend most of your spare time on this stuff while the download
> counter reaches the "100" mark. I really need more feedback.

Exactly. Pardon me but the way you presented things in your previous posts
on this subject didn't exactly prompt me to contribute.

Again, I buy many of the arguments you give. That channel access stuff
etc. is self-evident. I just feel that these things should be discussed
before making hasty decisions. Especially as it seems you want to drop
things that are concidered important by others.

You are of course entitled to do as you please but if the real world isn't
taken into account, I fear your valuable work ends up something only your
"group of high standards" knows about...

Anyway we now have discussion and that is good.

> I my opinion only configuration should be in /proc. Thatīs settings, port
> status, ax25 circuit list (for reading only of cause) etc. Thatīs mostly
> what it consists of now, so it should stay there. What I have a bad feeling
> about is that terminal programs begin scanning /proc/net/ax25 to find out
> about L2 state of "their" sockets just to display them. They IMHO ought to
> use the ioctl() interface.

As I said, that /proc reading stuff was written for node. Jonathan then
thought it should be moved to the lib so others could use it. In node it
is only used to give the user information about what is happening in the
system. I don't see what's wrong in that.

Oh, and it's also used to get the NET/ROM routing info from kernel in
order to do mnemonic->callsign translation. Currently there is no other
way and I see little reason to change that.

We have seen wrongful uses of the stuff but (now that the ioctl interface
is powerful enough) they have been rectified. I'm not buying it should be
removed just because someone could use it for wrong purposes.

> Another thing is trying to find ax25-Interfaces. Some apps scan the proc
> entries instead of using ioctl()s. They break when proc format changes.
> In my opinion procfs should be reserved for user interaction with standard
> tools such as "cat", "grep" etc, applications and tools should use the
> ioctl() interfaces.

What apps? That's seems just plain stupid. Anyway in my opinion "when proc
format changes" is entirely analogous to "when the kernel api changes". If
something changes in the API the apps break just as if they would when a
proc file format changes. That should just be avoided! And if it cannot be
avoided then it should be hidden behind a library anyway.

-- 
Tomi Manninen           Internet:  [EMAIL PROTECTED]
OH2BNS                  AX.25:     [EMAIL PROTECTED]
KP20ME04                Amprnet:   [EMAIL PROTECTED]

Reply via email to