Date: Wed, 27 Sep 2000 22:42:54 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Robert Clark <res03db2@gte.net> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Ideas about network interfaces. Message-ID: <20000927224254.H7553@fw.wintelcom.net> In-Reply-To: <200009280418.VAA01234@gte.net>; from res03db2@gte.net on Wed, Sep 27, 2000 at 09:18:38PM -0700 References: <200009280418.VAA01234@gte.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Robert Clark <res03db2@gte.net> [000927 21:19] wrote:
> A few ideas that've been in the back of my head.
>
> Would it make sense to have network device names abstracted one layer more?
>
> In other words, would it make it easier for new users, if all network
> drivers were mapped to something like et0?
>
> This might remove some of the need for rewriting rc.firewall on a newly
> isntalled system.
>
> With a symbolic name for interfaces, there could one that defaulted to
> deny everything.
This is why shell scripts allow for variables like:
outside_interface="fxp0"
> Being able to partition one FreeBSD system into multiple virtual routers
> would be a nice cabability as well. I wonder if that sort of thing
> would be possible, without totally gutting the network stack.
A url explaining what a "virtual router" is would be nice, if you
mean vlan, i'm pretty sure there's support:
(from 'man ifconfig')
vlan vlan_tag
If the interface is a vlan pseudo interface, set the vlan tag
value to vlan_tag. This value is a 16-bit number which is used to
create an 802.1Q vlan header for packets sent from the vlan in-
terface. Note that vlan and vlandev must both be set at the same
time.
If not I'm not sure what you mean.
> I've heard of "capabilities" being brought over into FreeBSD. Would this
> eventually lead to a version of FreeBSD that knows even more about
> running processes?
Er, we could associate more information with processes, but by nature
FreeBSD knows as much about a process as a process does.
> I hoping that eventually, FreeBSD will be able to "fink" on bad processes.
> I've often wondered that relying on a sysadmin to figure out which
> process went south is less than optimal.
There exists tools to do such things in ports/security, i'm sure other
things could be fitted into the system such as logging signals that
are sent as well as file descriptors.
> Sorry, that sentence didn't come out right. At the moment, the BSDs are
> the bright spot in the OS universe. I have more hope that good things
> will come from them. UNIX continues to mature, but for all its glory, it
> has its rough spots too.
>
> An analogy, a weak one, would be ethernet. Ethernet has dominated the
> market. Its everywhere. But I'd argue that one of its biggest weaknesses
> is that it knows nothing of itself.
>
> When ethernet is overutilised, it just stops being optimal. Without a person
> figuring out what is going on, it just keeps bein suboptimal.
>
> ATM on the other hand, (if I understand it correctly), is aware of its limits.
> It hopefully would not allow itself to be oversubscribed. It either has
> the capacity to handle your traffic, or it does not. But either way it will
> tell you so.
An ethernet can have devices attached such that overutilization is
detected, many algorithms exist to detect various network problems
that occur on ethernet.
> Or look at file systems. Why is any part of a disk ever allowd to be empty?
> It costs the same to keep them running, whether they're empty or full.
I'm not sure what we'd fill them with, perhaps a suggestion?
> Or look at interprocess signals. Why don't we have a standardized signal
> for "please store state, and shut down cleanly"? Or one for "please
> reload state, and return to service"?
Tradition is SIGTERM is shut down and SIGHUP is reload.
> Thank you for taking the time to read these questions, and thank you for
> a forum to ask these kinds of questions.
>
> [RC]
>
Er, sure thing. :)
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000927224254.H7553>