1.) smbfs kernel module (800K),smbmount(800k), smbumount(6.8k),smbmnt(9k) total 1614.8K 2.) cifs kernel module (2000K),mount.cifs(20K),umount.cifs(6K) total 2026K
flash space is limited. fireether wants to use cifs, i say use smbfs. This is for mounting ONLY. the smbclient, and client shared library add another 2M. CIFS does have a lot more features and is totally backwards compat with smb, however, smb has a better footprint size, and all the basic functionality users should "need"
Right now the smb.patch that I have posted enables BOTH kernel modules. and samba packages that I packed have BOTH smb and cifs.
> flash space is limited. fireether wants to use cifs, i say use smbfs. > This is for mounting ONLY. > the smbclient, and client shared library add another 2M.
These would be required for gui browsing the "network". Mounting does not require smbclient, and libsmbclient share lib.
On Fri, 2006-11-03 at 09:05 +0000, Tom Bruno wrote: > Fireether and I have been working with samba.
> Details:
> 2 methods of mounting samba sahres:
> 1.) smbfs kernel module (800K),smbmount(800k), > smbumount(6.8k),smbmnt(9k) total 1614.8K > 2.) cifs kernel module (2000K),mount.cifs(20K),umount.cifs(6K) total > 2026K
> flash space is limited. fireether wants to use cifs, i say use smbfs. > This is for mounting ONLY. > the smbclient, and client shared library add another 2M. CIFS does > have a lot more features and is totally backwards compat with smb, > however, smb has a better footprint size, and all the basic > functionality users should "need"
> Right now the smb.patch that I have posted enables BOTH kernel modules. > and samba packages that I packed have BOTH smb and cifs.
uh, sorry to be a disheartner, but that only leaves 2.5mb ... we WILL need that much, and probably more as time goes on...
How much can the existing stuff be optimized? - can certain things be compressed?
Why have samba in the distributed firmware? - the technical troubles for someone to setup a network at home are huge, and something like an ftp server running on the OSD could be much better.
On a happier note: i'm excited by this - it finally means that the OSD can have more of a use. (but at what cost)
> > flash space is limited. fireether wants to use cifs, i say use smbfs. > > This is for mounting ONLY. > > the smbclient, and client shared library add another 2M. CIFS does > > have a lot more features and is totally backwards compat with smb, > > however, smb has a better footprint size, and all the basic > > functionality users should "need"
> > Right now the smb.patch that I have posted enables BOTH kernel modules. > > and samba packages that I packed have BOTH smb and cifs.
> Why have samba in the distributed firmware? - the technical troubles > for someone to setup a network at home are huge, and something like an > ftp server running on the OSD could be much better.
They arent that huge. Most homes already use cable/dsl routers and such. As far as setting up "shares" all you do is right click on a folder and click on "Share". What including this support does is actually finalize connectivity to windows machines. Which sadly is much more important than web servers, scripting, and even linux filesharing. Having this support built in lets every average joe with no linux experience and having nothing but windows play and record video's to windows machines via network. Pretty important in my book.
> What including this support does is > actually finalize connectivity to windows machines. Which sadly is > much more important than web servers, scripting, and even linux > filesharing. Having this support built in lets every average joe with > no linux experience and having nothing but windows play and record > video's to windows machines via network. Pretty important in my book.
I'd say fundamental. Compatibility with windows shares should be a priority feature. Scripting is a features that appeals to the closet geek audience at best, while browsing smb shares is a feature that appeals even the average user (for some reason i'm always wary of saying "the average joe" in this list ;))
I think some good news is as far as size consern is that both smbclient, and libsmbclient.so aren't required for smb network browsing :) osdmain will just have to link to libsmbcleint.so this cuts out another 900K. So using only smb:
smbfs kernel module (800K) smbmount(800k), smbumount(6.8k) smbmnt(9k) smb's character set (28k) libsmbclient.so (1640K) for a total of: 3283.8k 3.3M
its large... but a must have for network interaction. I don't know about cifs.. cifs setup:
cifs kernel module (2000K) mount.cifs(20K) umount.cifs(6K) smb's character set (28k) libsmbclient.so (1640K) 3694K 3.7M
Question is.. do we need cifs features.. and is the kernel module worth the weight. remember, the kernel module will be loaded into ram...
I haven't done testing (my network has no SMB shares), but I know on AMD64 that the file sizes are: libsmbclient.so (1841720) libfuse.so (79960) fuse.ko (62548) fusesmb (40992)
for a total of: 2025220 1977K 1.9M
I haven't tested it or anything, and I'm not advocating it by any means, just throwing it out there.
Well. we've worked with fuse a little last night. Come to find out fuse requires kernel module, and smbfs module as well, from what we have seen. Fusesmb also requires most of the tools included in the samba package. Like nmblookup and all sorts of others.
Its a nice concept package but, it seems to depend on and use almost all of the differet (large) parts of the full samba package that we took out to get the sizes we are talking about :)
We are looking into it more of course to get definite sizes.
Tom Bruno wrote: > > flash space is limited. fireether wants to use cifs, i say use smbfs. > > This is for mounting ONLY. > > the smbclient, and client shared library add another 2M.
> These would be required for gui browsing the "network". Mounting > does not require smbclient, and libsmbclient share lib.
On Nov 5, 9:07 pm, "j...@neuros.com.cn" <j...@neuros.com.cn> wrote:
> Hi, everyone I am the osd developer in china. I think we just only use > smbfs.ko . But I can not find smb.ko .
smbfs.ko is located in the linux kernel config. You can enable it by my patch that smb.patch in the very first post. Or set the option: CONFIG_SMB_FS=m in your kernel .config file then rebuild the kernel and modules.
The kernel module only enables samba shares to be block devices. You still need the tools to mount and use the smb network. the tools, can also be found in the link provided with the first post. http://www.limesg.com/osd/samba/samba-3.0-OSD-client.tar.bz2
Inorder to allow OSD main to "browse" the windows network live like Network Neighborhood does in Microsoft Windows, libsmbclient.so will be required.
There are 2 systems, mounting, and browsing. the kernel module makes mounting available. You have to know the address and share name to mount though. Browsing allows you to just look at the network. JoeBorn expressed a lot of interest in the ability to browse.
> Tom Bruno wrote: > > > flash space is limited. fireether wants to use cifs, i say use smbfs. > > > This is for mounting ONLY. > > > the smbclient, and client shared library add another 2M.
> > These would be required for gui browsing the "network". Mounting > > does not require smbclient, and libsmbclient share lib.
Here's a thought that goes back to the choice between smbfs and cifs. Isn't it true that the normal share created by Windows XP (and thus also Vista) is a CIFS share and thus unusable by smbfs? If that is the case (and I think it is, judging by hurdles I've had to jump with my regular Linux box) saving the 200 kb by using smbfs instead of cifs will prevent the vast majority of users from having instant usability...
You should, of course, verify this. If it's true, then I think the best option would then be to use the CIFS and offer a hacking bounty to remove some code from the CIFS module (perhaps all the authentication code? then you could just have the qualifier "works only with unpassworded shares")
Tom Bruno wrote: > On Nov 5, 9:07 pm, "j...@neuros.com.cn" <j...@neuros.com.cn> wrote: > > Hi, everyone I am the osd developer in china. I think we just only use > > smbfs.ko . But I can not find smb.ko .
> smbfs.ko is located in the linux kernel config. You can enable it by > my patch that smb.patch in the very first post. Or set the option: > CONFIG_SMB_FS=m in your kernel .config file then rebuild the kernel > and modules.
> The kernel module only enables samba shares to be block devices. You > still need the tools to mount and use the smb network. > the tools, can also be found in the link provided with the first post. > http://www.limesg.com/osd/samba/samba-3.0-OSD-client.tar.bz2
> Inorder to allow OSD main to "browse" the windows network live like > Network Neighborhood does in Microsoft Windows, libsmbclient.so will be > required.
Thanks, How to use libsmbclient.so ? How to know the API it supply ? And if we want to search the smb server on network, how to enable it ? Smbclient need the ip .I think there are some way to search server without a offered ip.
> There are 2 systems, mounting, and browsing. the kernel module makes > mounting available. You have to know the address and share name to > mount though. Browsing allows you to just look at the network. > JoeBorn expressed a lot of interest in the ability to browse.
> > Tom Bruno wrote: > > > > flash space is limited. fireether wants to use cifs, i say use smbfs. > > > > This is for mounting ONLY. > > > > the smbclient, and client shared library add another 2M.
> > > These would be required for gui browsing the "network". Mounting > > > does not require smbclient, and libsmbclient share lib.
On Nov 6, 9:44 pm, "Popeman" <Richard.Sheri...@gmail.com> wrote:
> Here's a thought that goes back to the choice between smbfs and cifs. > Isn't it true that the normal share created by Windows XP (and thus > also Vista) is a CIFS share and thus unusable by smbfs?
Windows XP can be mounted via smbfs. mount -t smbfs uses smbfs. I do not know about vista, but in reality, the differences in smb and cifs are almost nil. If it can be verified that smbfs won't mount Vista shares then by all means, we need to move to cifs.
> You should, of course, verify this. If it's true, then I think the > best option would then be to use the CIFS and offer a hacking bounty to > remove some code from the CIFS module (perhaps all the authentication > code?
The authentication code is part of the protocol to say "unset password" you still need the authentication code to say "no password". This is not a good idea anyway.
> And if we want > to search the smb server on network, how to enable it ? Smbclient need > the ip .I think > there are some way to search server without a offered ip.
I did not include all the tools. nmblookup is needed to "find machines" on the network. As far as the samba api. it is well documented at www.samba.org. all you would need is libsmbclient.so in my package and the header file libsmbclient.h from the source. The header file also has the api in it.
Outside of that is reaching past my knowledge of the samba libraries, but I look forward to diving farther into it later this week.
It seems cifs can be used to mount smb server both windows and linux . I do not know if still need smbfs in osd . And the libsmbclient.so seems provides file operations for smb read/write/open . But after mount we can operate the files just like the ones in local machine. I think i need the smb protocol to develop search samba server function or if threr is somebody know perl well can help me understand findsmb.
On Nov 9, 4:01 am, "j...@neuros.com.cn" <j...@neuros.com.cn> wrote:
> It seems cifs can be used to mount smb server both windows and linux > . I do not know if still need smbfs in osd .
This is correct. If you read the first post, I explian differences and what each piece of software is for. the major difference between smbfs.ko and cifs.ko is not what they do, but thier size.
Yes the modules allow us to mount the file system and use it as a block device. It is not that simple though. cifs.ko is 2 megabytes in size and smbfs.ko is 800 kilobytes. On flash ram this matters a lot.
Also, the ability to mount requires tools to mount. mount.cifs/umount.cifs and smbmount.
In the first post and several afterwords are about the different sizes and which would be the best choice.
And the libsmbclient.so
> seems provides file operations for smb read/write/open .
yes, libsmbfsclient.so would be used for osdmain to browse the "windows network"
>But after mount we can operate the files just like the ones in local machine.
this is a true statement, however the problem with mounting is it works different than browsing. Mounting you have to know the ip address and all the details of the network share then you give the mount command. Live browsing and usage in osdmain don't mount. You would use libsmbfsclient funtions to find the network share, ip, and then your code would run the mount command.
> I think i need the smb protocol to develop search samba server function > or if threr is somebody know perl well can help me understand findsmb.
libsmbclient.so docuementation should provide you with everything you need as far as building c/c++ tools to search.
Please take some time and read the previous posts on the list so we don't have to keep reposting the same data. Thank you.
To my shame, Dave Jones made me realize today that i was building the modules with debugging symbols. Without the symbols, the modules are only about 200k.
He also made a very good arguement on why to use cifs. and since cifs is only 261k, not 2000, well then.. cifs it is.
Tom Bruno wrote: > To my shame, Dave Jones made me realize today that i was building the > modules with debugging symbols. Without the symbols, the modules are > only about 200k.
> He also made a very good arguement on why to use cifs. and since cifs > is only 261k, not 2000, well then.. cifs it is.
> I will be posting an upk with samba connectivity.
|
