Message-Id: <1250725697.6047.27.camel@zuul.thistledown>
Date:	Wed, 19 Aug 2009 17:48:17 -0600
From:	Alex Tsariounov <alext@...ell.com>
To:	Joel Becker <Joel.Becker@...cle.com>
Cc:	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	"Michael S. Tsirkin" <mst@...hat.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	alacrityvm-devel@...ts.sourceforge.net,
	Anthony Liguori <anthony@...emonkey.ws>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [Alacrityvm-devel] configfs/sysfs

On Wed, 2009-08-19 at 15:16 -0700, Joel Becker wrote:
> On Wed, Aug 19, 2009 at 11:12:43PM +0300, Avi Kivity wrote:
> > On 08/19/2009 09:23 PM, Nicholas A. Bellinger wrote:
> > >Anyways, I was wondering if you might be interesting in sharing your
> > >concerns wrt to configfs (conigfs maintainer CC'ed), at some point..?
> > 
> > My concerns aren't specifically with configfs, but with all the text
> > based pseudo filesystems that the kernel exposes.
> 
> 	Phew!  It's not just me :-)

The points on *fs vs. ioctl are interesting.  I think both have their
benefits and both have the downfalls, for example efficiency vs. ease of
(human) use. I suppose it comes down to whether you're in the fast path
or not for the most part.  However, just because and interface is not as
efficient as it can be does not necessarily mean that it's not a good
one.

As as an example, many moons ago, I worked on implementing some serial
comms between an embedded speed controller and its command console.
Being young and efficiency starved ;) I disregarded our other
controllers which implemented these serial comms with ASCII strings, and
used binary blobs instead.  I indeed got some respectable performance
out of doing this, even to the effect of creating a "real time" status
monitor that updated multiple times a second via the hand-held terminal.

However, I totally missed the point of intentionally doing things
"inefficiently."  For example, our serial debugging setup consisted of
two VT100 terminals wired up with a custom serial cable that went
between two communicating units.  Each term would show what each end was
saying.  Kinda crude, but effective.  Of course with my new and improved
controller that "spoke the binary language of moisture evaporators,"
well, all one saw was garbage.  :)

Additionally, someone debugging the controllers could just use a term to
talk to it if it used simple ASCII commands and take terminals, hosts
and other software out of the picture, but for my controller, well, you
could only use the custom programmed hand-held term.

I ended up supporting both ASCII and binary communications on the
controller for these (and other) reasons.  However, in the end, I
ditched the binary comms since they really didn't add the efficiency in
the fast path where it should be added.  (Well, I also ran out of eprom
space... :)

In any case, having a humanly understandable communications protocol (or
ABI) can be extremely useful, and just because it's not efficient
doesn't automatically mean that it's a bad thing, especially if it's in
the slow path.  It does have it's down sides as mentioned in this
thread, so we really need both types.  Because of that, the fuse layer
on top of a binary ABI is an interesting idea.

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists