NetBSD on Cobalt Networks MIPS based Qube and RaQ computers (NetBSD/cobalt)

Markus W Kilbinger | 9 May 2005 22:55

Picon

Re: mount_smbfs problems

>>>>> "Hubert" == Hubert Feyrer <hubert <at> feyrer.de> writes:

    Hubert> Index: etc.cobalt/MAKEDEV.conf
    Hubert> ===================================================================
    Hubert> RCS file: /cvsroot/src/etc/etc.cobalt/MAKEDEV.conf,v
    Hubert> retrieving revision 1.2 diff -u -r1.2 MAKEDEV.conf
    Hubert> --- etc.cobalt/MAKEDEV.conf 19 Oct 2003 19:07:27 -0000 1.2
    Hubert> +++ etc.cobalt/MAKEDEV.conf 9 May 2005 20:42:21 -0000
    Hubert>  <at>  <at>  -7,6 +7,7  <at>  <at> 
    Hubert>          makedev tty00 tty01 tty02 tty03 makedev isdns
    Hubert>          makedev scsibus0 scsibus1 scsibus2 scsibus3
    Hubert> + makedev nsmb
    Hubert>          ;;

I tried that on my qube, it's not sufficient, because the makedev
logic relies on device numbers in
/usr/src/sys/arch/cobalt/conf/majors.cobalt where _no_ entry for nsmb
exists. -> Somebody has to add it...

Markus.

Hubert Feyrer | 9 May 2005 23:06

Picon

Re: mount_smbfs problems

On Mon, 9 May 2005, Markus W Kilbinger wrote:
> I tried that on my qube, it's not sufficient, because the makedev
> logic relies on device numbers in
> /usr/src/sys/arch/cobalt/conf/majors.cobalt where _no_ entry for nsmb
> exists. -> Somebody has to add it...

Grmbl. I recommend raising a PR.

  - Hubert

--

-- 
NetBSD - Free AND Open!      (And of course secure, portable, yadda yadda)

Alex Pelts | 9 May 2005 23:05

Re: mount_smbfs problems

Device node exists in i386, ALPHA, sparc and xen architecures. It seems 
to vary between numbers 77, 88, 98 and 134 with 98 being the most 
popular. On cobalt only nubers up to 37 are used and MAKEDEV script 
supports 98 out of the box. Why not add line:
device-major    nsmb            char 98                 nsmb
to majors.cobalt, recompile and try it out again?

Alex

Markus W Kilbinger wrote:
>>>>>>"Hubert" == Hubert Feyrer <hubert <at> feyrer.de> writes:
> 
> 
>     Hubert> Index: etc.cobalt/MAKEDEV.conf
>     Hubert> ===================================================================
>     Hubert> RCS file: /cvsroot/src/etc/etc.cobalt/MAKEDEV.conf,v
>     Hubert> retrieving revision 1.2 diff -u -r1.2 MAKEDEV.conf
>     Hubert> --- etc.cobalt/MAKEDEV.conf 19 Oct 2003 19:07:27 -0000 1.2
>     Hubert> +++ etc.cobalt/MAKEDEV.conf 9 May 2005 20:42:21 -0000
>     Hubert>  <at>  <at>  -7,6 +7,7  <at>  <at> 
>     Hubert>          makedev tty00 tty01 tty02 tty03 makedev isdns
>     Hubert>          makedev scsibus0 scsibus1 scsibus2 scsibus3
>     Hubert> + makedev nsmb
>     Hubert>          ;;
> 
> I tried that on my qube, it's not sufficient, because the makedev
> logic relies on device numbers in
> /usr/src/sys/arch/cobalt/conf/majors.cobalt where _no_ entry for nsmb
> exists. -> Somebody has to add it...
>

(Continue reading)

Markus W Kilbinger | 9 May 2005 23:30

Picon

Re: mount_smbfs problems

>>>>> "Alex" == Alex Pelts <alexp <at> broadcom.com> writes:

    Alex> Device node exists in i386, ALPHA, sparc and xen
    Alex> architecures. It seems to vary between numbers 77, 88, 98
    Alex> and 134 with 98 being the most popular. On cobalt only
    Alex> nubers up to 37 are used and MAKEDEV script supports 98 out
    Alex> of the box. Why not add line: device-major nsmb char 98 nsmb
    Alex> to majors.cobalt, recompile and try it out again?

Are these dev numbers that kind of free choice!?

    Hubert> Grmbl. I recommend raising a PR.

Probably the best/clean way to get it done...
A privilege for the thread initiator... 

Markus.

Alex Pelts | 9 May 2005 23:41

Re: mount_smbfs problems

 From my experience with Linux, numbers more or less are free choice. As 
long as the number does not conflict with any other number it will be 
OK. The only layer who needs to know the node/driver mapping is VFS 
layer. It will invoke the right driver upon operation on the special file.

Linux maintains one text file containing mapping between devices and 
major numbers. I was surprised not to find one in NetBSD. There is one 
file per port defining the same thing, although numbers for the same 
device are different on different ports.

I am not at all opposed raising a PR, just to solve Justin's problem 
right now, he can try adding the line and recompiling..

Maybe PR should be raised to reconcile all the numbers on different 
ports and all all the missing ones?

Regards,
Alex

Markus W Kilbinger wrote:
>>>>>>"Alex" == Alex Pelts <alexp <at> broadcom.com> writes:
> 
> 
>     Alex> Device node exists in i386, ALPHA, sparc and xen
>     Alex> architecures. It seems to vary between numbers 77, 88, 98
>     Alex> and 134 with 98 being the most popular. On cobalt only
>     Alex> nubers up to 37 are used and MAKEDEV script supports 98 out
>     Alex> of the box. Why not add line: device-major nsmb char 98 nsmb
>     Alex> to majors.cobalt, recompile and try it out again?
>

(Continue reading)

Martin Husemann | 9 May 2005 23:49

Picon

Re: mount_smbfs problems

On Mon, May 09, 2005 at 02:41:23PM -0700, Alex Pelts wrote:
> Maybe PR should be raised to reconcile all the numbers on different 
> ports

Why would you want to do that?
And if you want to do it, please provide a devnode-mapping filesystem
for compat uses (/emul/*/dev) first.

Martin

Alex Pelts | 9 May 2005 23:55

Re: mount_smbfs problems

I did not understand what you mean exactly, could you elaborate please?

Thanks,
Alex

Martin Husemann wrote:
> On Mon, May 09, 2005 at 02:41:23PM -0700, Alex Pelts wrote:
> 
>>Maybe PR should be raised to reconcile all the numbers on different 
>>ports
> 
> 
> Why would you want to do that?
> And if you want to do it, please provide a devnode-mapping filesystem
> for compat uses (/emul/*/dev) first.
> 
> Martin
> 
> 
>

Martin Husemann | 10 May 2005 00:03

Picon

Re: mount_smbfs problems

On Mon, May 09, 2005 at 02:55:30PM -0700, Alex Pelts wrote:
> I did not understand what you mean exactly, could you elaborate please?

My main point was:
since noone cares for the actual numbers, why do you want to reconcile them?

IIRC they were chosen to help certain compat setups where you use a /dev
dir from another OS in one way or the other. A special layered filesystem
(similar to UMAPFS) that maps device nodes according to a config file
could be used to assist this setups instead and allow globaly unique device
major numbers.

But then, changing those numbers now, after lots of machines are installed,
would be a major PITA.

Martin

Hubert Feyrer | 10 May 2005 00:47

Picon

Re: mount_smbfs problems

On Tue, 10 May 2005, Martin Husemann wrote:
> IIRC they were chosen to help certain compat setups where you use a /dev
> dir from another OS in one way or the other. A special layered filesystem
> (similar to UMAPFS) that maps device nodes according to a config file
> could be used to assist this setups instead and allow globaly unique device
> major numbers.

It seems most[1] ports use majors below 143 for MD drivers, and >143 for 
MI drivers. I wonder why smb uses MD specific numbers in the first place.

  - Hubert

[1] sys/arch/pmppc/conf/majors.pmppc says 143 in one place, and 191
     in another. Need to bug Lennart...

--

-- 
NetBSD - Free AND Open!      (And of course secure, portable, yadda yadda)

Jaromir Dolecek | 10 May 2005 01:53

Picon

Re: mount_smbfs problems

On Tue, May 10, 2005 at 12:47:13AM +0200, Hubert Feyrer wrote:
> On Tue, 10 May 2005, Martin Husemann wrote:
> >IIRC they were chosen to help certain compat setups where you use a /dev
> >dir from another OS in one way or the other. A special layered filesystem
> >(similar to UMAPFS) that maps device nodes according to a config file
> >could be used to assist this setups instead and allow globaly unique device
> >major numbers.
> 
> It seems most[1] ports use majors below 143 for MD drivers, and >143 for 
> MI drivers. I wonder why smb uses MD specific numbers in the first place.

The MI range has not been assigned at the time smbfs got into the tree.
Since it appears reasonably MI now, I'm adding this to all platform
major lists now.

> [1] sys/arch/pmppc/conf/majors.pmppc says 143 in one place, and 191
>     in another. Need to bug Lennart...

Fixed.

Jaromir

--

-- 
Jaromir Dolecek <jdolecek <at> NetBSD.org>            http://www.NetBSD.cz/
-=- We can walk our road together if our goals are all the same;     -=-
-=- We can run alone and free if we pursue a different aim.          -=-

Alex Pelts | 10 May 2005 00:24

Re: mount_smbfs problems

I agree with you on the point of changing large install base. I was just 
thinking that having all the numbers different on all the different 
ports does not help the understanding.

I guess there is a little point to have all the numbers change but it 
would be nice if the new numbers would match the existing ones. This way 
new user would not spend much time trying to figure out what number to 
assign. The document describing details would be nice as well (if there 
isn't one already).

One thing I am kind of surprised about is that no one run in to this 
problem before. I can't believe that no one tried to run samba server on 
the qube.

Thanks,
Alex

Martin Husemann wrote:
> On Mon, May 09, 2005 at 02:55:30PM -0700, Alex Pelts wrote:
> 
>>I did not understand what you mean exactly, could you elaborate please?
> 
> 
> My main point was:
> since noone cares for the actual numbers, why do you want to reconcile them?
> 
> IIRC they were chosen to help certain compat setups where you use a /dev
> dir from another OS in one way or the other. A special layered filesystem
> (similar to UMAPFS) that maps device nodes according to a config file
> could be used to assist this setups instead and allow globaly unique device

(Continue reading)

Justin Newcomer | 10 May 2005 00:38

Picon

Re: mount_smbfs problems

I do and did run the samba server on the qube, lots of people do, its
running the smb client that became a problem.

I applied the changes to majors.cobalt
device-major    nsmb            char 98                 nsmb

and since I havent actually be able to build the -current userland
without it failing on some missing file error (even though i used cvs,
nother time, nother thread)

so i updated my MAKEDEV
with the suggestion from Hubert

       nsmb*)
               unit=${i#nsmb}
               mkdev nsmb$unit c 98 $unit 644
               ;;

i had the create the devices manually "./MAKEDEV nsmb"
but then everything worked
thank you all

the userland i have right now is from the 2.01 restore CD, but the
kernel has been recompiled several times to test and add / disable
things

one thing, the GENERIC kernel doesnt even have the "pseudo-device" or
the "file-system" options included (even with the #) so i had to copy
them from the i386 kernel

(Continue reading)

Return

Return to gmane.os.netbsd.ports.cobalt.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane