Hi folks, I'm trying to modify Wine's SMB code to use Netbios(), rather than implementing NetBIOS-over-TCPIP itself. I'm having trouble figuring out how to handle the fd_ops in the wineserver. I was hoping for input.
Currently, the SMB code creates a socket directly, and this socket is polled by the server for readability.
Netbios() hides a connection behind an 8-bit adapter index and an 8-bit session index, so there's no way (through the Netbios() interface) to get the socket handle being used for a connection.
Any opinions on whether (and if yes, how) the polling should be done?
One possibility might be to figure out the TDI stuff, as using TDI for NetBIOS allows you to avoid the Netbios() interface. However, I haven't found any public documentation for the TDI interface to NetBIOS, except perhaps in the NT DDK (whose license I think is problematic).
Any suggestions appreciated. Thanks, --Juan
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Juan Lang juan_lang@yahoo.com writes:
Hi folks, I'm trying to modify Wine's SMB code to use Netbios(), rather than implementing NetBIOS-over-TCPIP itself. I'm having trouble figuring out how to handle the fd_ops in the wineserver. I was hoping for input.
Frankly, I think the current SMB file support belongs in the kernel, and from Wine they should be accessed as normal files. The current approach is going to prevent a lot of interesting optimizations, since we need to special case all file operations instead of going straight to the kernel.
--- Alexandre Julliard julliard@winehq.com wrote:
Frankly, I think the current SMB file support belongs in the kernel, and from Wine they should be accessed as normal files. The current approach is going to prevent a lot of interesting optimizations, since we need to special case all file operations instead of going straight to the kernel.
Perhaps. You mean, extend smbfs in some way? My goal goes beyond file support. I want to provide a network neighborhood browser for wine. I suppose the entire NetBIOS namespace could be loaded in the kernel and loadable by Wine.. dynamically, of course, no need to populate it until it's requested. Even so, more than file read/write semantics are needed, or some creative special devices would be needed on each remote node for RAP and named pipes.
I've already tweaked the SMB code (locally) to dynamically load winsock/netapi32. The SMBs I need to send can't be sent using any other public/documented APIs, unfortunately. I've implemented NetServerEnum and NetShareEnum using them, and I think it's a short step until opening a remote named pipe is possible, too. It all benefits from the NetBIOS name lookup suff I added to Netbios()--if a name is resolvable via Netbios(), then you'll be able to call NetShareEnum on it, open a named pipe on it, etc. (Since RPC is typically layered on named pipes, the 'R' in Wine's RPC might start to mean something too.)
So, I think I have a submittable patch here, except that the current file stuff won't be able to poll if the connection is using Netbios(). I know I'm extending the current hack, perhaps in a direction you don't want it to go.
To wrap up, I'm curious: - is the current wineserver polling that valuable, that I should try to find a way around the Netbios() interface to maintain it? (A private API is the only solution I know for now. If someone has decent documentation on the TDI interfaces to NetBIOS or SMB I'd be interested in seeing it.) - should I submit what I have here for further review?
- should I mothball what I have in favor of a different approach?
Thanks for your time, --Juan
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
Juan Lang juan_lang@yahoo.com writes:
So, I think I have a submittable patch here, except that the current file stuff won't be able to poll if the connection is using Netbios(). I know I'm extending the current hack, perhaps in a direction you don't want it to go.
Polling is not really needed for normal files anyway. Feel free to submit what you have, it's still useful to have the code, even if it needs to be moved somewhere else later on. And I think most of the name lookup etc. can be done in user space, it's only the file I/O itself that has to be in the kernel IMO.
-
Alexandre Julliard -
Juan Lang