Jarommr> Though, this should have been done that the original
    Jarommr> FreeBSD version would be cvs imported, and NetBSD changes
    Jarommr> would be committed separately.  First and foremost, the
    Jarommr> NetBSD specific changes are localized and it would be easy
    Jarommr> to sync with FreeBSD changes. Second, it would make the
    Jarommr> process of feeding back NetBSD changes to FreeBSD much
    Jarommr> easier.

except that between the n different api differences between net and
freebsd, there were already a bunch of changes that were going to make
merging in new versions rather difficult.  when i started working on
this it wasn't in the freebsd tree, and i'm afraid i haven't been paying
attention to that recently.  and ubcification is going to add another
big difference.

so i wasn't really intending on doing future imports.

    Jarommr> I'd also preferred if the thing (commit of smbfs support)
    Jarommr> was discussed first. There might be some architectural
    Jarommr> issues which should have been solved before commit - like I
    Jarommr> think netsmb code should be in under smbfs, it's not adding
    Jarommr> different network stack (or is it ?).

ah, perhaps you're right.  i'm happy to move the smb code (which runs on
top of tcp) into smbfs if that's more appropriate.

    Jarommr> Re: iconv vs. codeconv - I'm not actively working on
    Jarommr> codeconv ATM.  So it's probably OK to use the FreeBSD iconv
    Jarommr> for now. It would be nice to discuss features of iconv API
    Jarommr> and possibly make the routines common to filesystems which
    Jarommr> need file name recoding engine (ntfs, Joliet cd9660,
    Jarommr> msdosfs). But this is separate issue from smbfs.

iconv.c in there is stubbed, mostly.  a real API/implementation is cool
when you've got it.  i'm not familiar w/ iconv stuff at all.

cheers,
matt