Re: userland access to devices is moving!
From: Matthew D. Fuller (fullermd_at_over-yonder.net)
Date: 06/18/03
- Previous message: Poul-Henning Kamp: "Re: userland access to devices is moving!"
- In reply to: Poul-Henning Kamp: "userland access to devices is moving!"
- Next in thread: Poul-Henning Kamp: "Re: userland access to devices is moving!"
- Reply: Poul-Henning Kamp: "Re: userland access to devices is moving!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 18 Jun 2003 12:47:33 -0500 To: Poul-Henning Kamp <phk@phk.freebsd.dk>
On Wed, Jun 18, 2003 at 05:35:19PM +0200 I heard the voice of
Poul-Henning Kamp, and lo! it spake thus:
>
> I sat down and hacked up a simple prototype to test the concept I
> have been rambling about for some years: Going directly from
> filedescriptor to device driver thus bypassing the vnode, devfs and
> specfs layer.
Speaking as somebody whose reach of mailing lists notably exceeds his
grasp (as it always should be; otherwise what fun is it?), I often find
myself a little in the dark on what these sort of things really /mean/ to
the system in the end, and I think it would be a nice extension of these
sort of posts/proposals to have a sentence of summary, along the lines
of:
What does this change /mean/ to the system as a whole? Is this
A) Cleaner code, so bugs can be found and fixed quicker and better,
B) Architectural improvement, so new features are easier to add on
cleanly and well, or
C) A real-world performance improvement. The benchmark you posted
certainly shows a significant improvement in SOMETHING; but is it a
something that will make mail servers or web servers or file servers
or workstations perk up?
I realize that they're not really exclusive conditions, and are mostly
intertangled. And, for that matter, that most changes don't get done
because of A, B, C, or any combination thereof, but more often because
"This is the ugliest mess I've ever seen and it's been haunting my dreams
for years, and I anyway I thought it would be fun to mess with." But I
for one would appreciate a quick note of a higher-level view of where
this can move us.
Of course this means I'm out of my depth. But everybody needs a hobby
:-}
-- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Poul-Henning Kamp: "Re: userland access to devices is moving!"
- In reply to: Poul-Henning Kamp: "userland access to devices is moving!"
- Next in thread: Poul-Henning Kamp: "Re: userland access to devices is moving!"
- Reply: Poul-Henning Kamp: "Re: userland access to devices is moving!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
- Re: I have been hacked (WAS: Have I been hacked or is nmap wrong?)
... > console based ftp client. ... the FTP servers have? ... >
They are really mail servers, at least smtp for outgoing mails ... If you're firewall
was dropping incoming packets destined to ... (freebsd-questions) - Re: DNS not resolving mail server for ADSL users
... > did I say my intention was to confuse, ... > to identify mail servers,
so it better to set up one as ... > of even one SMTP server that will be looking for
an MX ... Maybe the way you configure your mail servers, there is no need for internal
... (microsoft.public.win2000.dns) - RE: suggestions on a good firewall
... > guard feature which only lets mail servers receive the RFC 821 commands ...
the FTP Fixup allows traffic in on port 20 ... > commands that could be used
for nefarious purposes. ... (Security-Basics) - Re: Suspicious problem with Solaris 2.6
... any patches for at least 4 years because the servers have been totally ... in.telnet
and in.ftp has died sort ... reboot fixes the problem for only a short time. ...
Normally inetd would restart in.telnetd and in.ftpd... ... (comp.unix.questions) - Re: Which greylist milter is least maintenance
... If you have multiple mail servers and MX records a sending system, on receiving a tempfail,
will try the next. ... If that also has greylisting it will move to the next until it has
exhausted your mx list. ... If you have greylisting enabled on one but not all MX servers
you effectively have no greylisting for sending systems that are smart enough to retry. ... If
you have greylisting on all your systems and they each maintain their own database you effectively
have greylisting from hell. ... (comp.mail.sendmail)