ksmbd

[Guy Sotomayor]

> Interesting project--lends some definite credence to Luke's argument that
> functionality could/should be split.  Mix and Match ;-)
> 
> (Luke--it's also a reason for you to document your code if you ever
> want anybody to actually use it ;-)
> 
> Questions--
> 
> 1)  Licensing.  GPL?  LGPL?  Even the latter has trouble coexisting with
> the former, incidentally.
> 
Currently it was done on behalf of my employer so source is not available
at this time.  We'll see what develops as it gets closer to completion.

> 2)  How's speed relative to userspace smbd?
> 
As I said I haven't done any exhaustive performance analysis but a
heavily instrumented version of ksmbd uses about 1/2 the cpu resources
of the user space smbd running the same workload (netbench).

> 3)  smb.conf:  Used at all?  New config format?
> 
only to configure nmbd.  The user space "helper" daemon is
responsible for all configuration tasks.  ksmbd is configured
through /proc entries that it presents.

> 4)  How's stability, particularly under high loads?
> 
It was stable enough to run netbench without falling over.  It
wasn't really stressed too hard -- I was still getting all of
functionality in.  I had to stop working on it to take care of
other areas of the project (writing function specs, project
management, etc) that took all of my time/energy.

> 5)  Security.  Unless I'm mistaken, buffer overflows are a much more
> worrisome issue in kernel space, because you're talking about *really*
> small chunks of space and *really* sensitive chunks of memory.  This
> single fact makes any kernel space network daemon a touchy subject.  Not
> that they're all evil--apparently NFS is kernel by necessity, and Linus
> did speak rather highly of that tiny sendfile() http daemon that offloaded
> all dynamic pages to apache.  Just that you have to meet a much, much
> higher standard of benefit to override the costs.
> 
My 25+ years have been spent as a kernel hack.  So I'm aware of the
dangers associated with errant and/or sloppy kernel code.

> 6)  When can we play with it ;-)
I don't know (yet).


TTFN - Guy