Re: Miscellaneous comments and questions

> >The 'perm' error messages that I sometimes get when working in VSTa were
> >just frustrating.
>
>Note that some of this went away recently, when I removed some non-portable
>decoding of return status and used the appropriate wait.h macros.

Yes, I noticed it was a little more helpful recently. :-)

> >Add the fact that I have nowhere to check for command
> >options
>
>Except the source. :->

Yup. :-)

> >and that their are few man pages
>
>Guilty as charged. It's just that I thought the truly VSTa unique stuff
>would need documenting before things which behaved much like any other UNIX
>would.

Oh, definitely! The common commands are not really the problems I was having
much trouble with(though some command options are different than in Linux).
But you're right, the esoteric stuff first, the common stuff later.

>Not that it's a problem to ask!
>
>But I wouldn't mind having the archives searchable. I thought some of the
>search engines could actually do that (search within a given WWW domain
>only)--I know our mail archives are picked up by a couple of the big search
>engines.

Hmmm, I suppose that might work. I'll try google next time I have a problem
and see how that works out. Thanks for the tip. :-)

>Or if somebody has a good utility I could attach to CGI, I'd be happy to
>look into it.

I can't recommend one, but I'll keep an eye out.

>I've also been wondering if we shouldn't head off the well-beaten UNIX
>track
>and do a Tenex-style UI instead? Still with distinct utilities in their
>own
>processes beneath, but with command completion and context sensitive help
>integrated.

I'm not too familiar with Tenex. Is there some info you could point me to?

> >Why not just have the driver/servers themselves register generic
>interface
> >names? Instead of 'net/ne2000' (or something similar), register
>'net/eth0'
> >as the first network card, 'net/eth1' as the second, etc.
>
>How does the first know it's supposed to be first?

Well, I figured it would just try registering the first and if namer
returned an error saying it was already taken, then it try the second and so
on. The drivers would simply need to be started in the proper order(in
reading your message I realized a problem with this which I'll illustrate
later).

>Also, this isn't at all
>what a UNIX-ish environment does (not that this is a guarantee that it's
>the
>right way to go).

Well, I don't claim to know that much about this subject. Perhaps I just
misunderstood the problem.

> >A simple loop while registering a name for the server would simplify
>things
> >greatly for ka9q(in semi-pseudo code):
> >char *name = "net/eth0";
> >n = strlen(name)-1;
> >while(name[n] <= '9') {
> > /* attempt to register name here, if successful, break */
> > name[n]++;
> >}
> >printf("registered: %s\n",name);
>
>Well, that would *find* them, but in pretty much every IP network I've ever
>used you need to relate a deterministic IP address and netmask to the
>physical interface.

Isn't that ka9q;s problem? Does the server, or ka9q determine addressing for
the interfaces? (I'm under the impression that ka9q takes care of that) If
ka9q does it then it has to find what drivers are running in the first
place, that's the problem I'm addressing. If not, then I'm totally off my
rocker. :-)

This is my current understanding of the problem: ethernet servers register
names that identify the particular server that is running(and hence what
card is in the machine), ie. 'net/ne2000'. Now ka9q needs to obtain the port
an ethernet server is listening on in order to communicate with it,
configure it with an ip, etc. However, in order to find a server, you need
the name it registered with so namer can return the port it serves requests
on. The current problem (as I understand it) is that the registered name
that is searched for is currently hard-coded into ka9q since it's impossible
to know ahead of time what ethernet server might be running(given the fact
that there are alot of different possibilities - not the case now, but
hopefully will be in the future :-).

A brute force solution would be to check every possibility, but that's not
very flexible since you would have to either change the source for each
additional driver, or add an entry in a configuration file which is read in
at run time. The option I suggested was to have the server register a
generic name for itself so it doesn't matter what driver is running. The
first driver to be started will always be 'net/eth0', the second
'net/eth1'(or some similar naimg scheme).

This has two benefits that I can see: a) it only requires the addition of a
simple loop in registering a name and searching for the port(so just simple
additions in the drivers and ka9q source), and b) enforces principle of
least priviledge(albeit in a somewhat superficial way) since it's not
possible to find out what hardware the machine has by examining the running
drivers(probably not that big a deal, but you never know; prevention is the
best way - not that I'm any security expert).

Now, the problem would be more complicated if each driver didn't have a
standard interface, ie. the message for sending a packet for 3com cards was
different than ne2000 cards, but that's not the case right?

> >Something similar to this would enable ka9q(or any other applications) to
> >use the drivers by just looking up the generic names instead of having to
> >know the name of the actual driver. Just a thought. :-)
>
>I'm open to suggestions, but in even non-UNIX environments (like, say, IOS)
>you want to name a specific physical interface, because there's a specific
>physical network attached to it.

Hmmm... Maybe I AM misunderstanding the issue. Say you have two network
cards('net/eth0' being a 3com, and 'net/eth1' being a ne2000), and you
configure them with a setup for a particular network. Then say you remove
the first one(3com card), the ne2000 will then register as 'net/eth0'
instead of its original 'net/eth1' and the configuration options for the
3com will be used for the ne2000; obviously a completely incorrect
situation. That is a serious problem with my idea. I'll have to think about
that, unless you already have a better solution to this problem(I'm very
curious how it's done, or how you're going to do it).

Thanks for your patience. :-)

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Received on Sat Feb 17 05:33:29 2001