[linux-cifs-client] Re: RFC 1001/1002 support

[Juan Lang]

Hi Chris, nice to meet you Steve.

--- "Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> > There had been a mapping in various IBM operating
> systems from Sockets
> > API over Netbios frame protocol (and presumably
> could be done for
> > SocketsAPI over RFC1001) but I doubt that this is
> interesting anymore -
> > especially to Linux people anymore, but there
> might be a case for
> > another API mapping into kernel.
> 
> I think there is.  It would make porting software
> from OS/2 and Windows 
> easier and I have had a few requests (not many, not
> that often, but I've 
> seen 'em).  I'll let Juan and Mike speak to the
> issues of Wine competing 
> with Samba and/or Linux SMB clients.

I agree there is interest (I've been asked a couple
times too), though I'd also agree with you Chris that
it may not be a lot.

Wine's two main issues are 1) the NBT ports are
already taken by Samba, and 2) integrating with a
userspace smbclient is difficult.  I'm sorry if this
is rehashing something you already know, but since
Chris asked I'll expand here:

1) has a lot of consequences.  We can't get the list
of backup master browsers, so we can't "play nice" in
the network neighborhood--we have to get the browse
list from the browse master.  (Chris, sorry for the
sloppy terminology).  We also can't defend names, so
we can't have NetBIOS datagram support.  And, most
obviously, we can't act as NetBIOS servers.

2) has two main reasons.  One is the smbclient API
through at least Samba3 is much too high-level to be
useful to Wine.  Another, just as important, is that
Wine is LGPL, and I don't have enough energy to
maintain a GPL fork of Wine to allow it to integrate
with a userspace Samba library.

Okay, enough pessimism, back to the fun stuff:

Like Chris, said, it'd be nice from Wine's perspective
to be able to implement the NetBIOS api on top of
this, and allowing for NBT/NBF/NBIPX independence
would be nice.  (Though not, of course, strictly
necessary.)

The main feature/quirk of the NetBIOS API that seems
worthwhile to keep is that of having a separate
interface for each NetBIOS virtual LAN.  In my
user-space NetBIOS implementation, for example, I
coalesce interfaces with the same IP subnet into one
LANA.

Chris, side note, out of laziness I only allowed one
NBT scope ID per wine instance (and wine instances
don't talk to each other).  If I allowed one per
interface like MS does I wouldn't coalesce those with
different scope IDs.

The NetBIOS API isn't totally clear about asynchronous
behavior.  A synchronous API from a kernel module
would be fine with me, as I already handle
asynchronous NCBs within Wine by spawning separate
threads for them.

Rather more interesting from Wine's point of view is
if we could implement named pipes or file I/O on top
of a kernel module.  For file I/O if we could send the
equivalent of a NtCreateFile (or the NT_CREATE_ANDX
SMB) that'd be just dandy, since that's what Wine uses
internally.

But I'm using up my floor time, so I'll hope for
interesting commentary from the next speaker :)
--Juan


	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash