Let me preface this with a </lurk> tag and the notice that I'm not 
a "BSD geek" so I don't know what the BSD way of doing things is, so
this should all be taken with a shaker or two of salt.

On Fri, Feb 09, 2001 at 06:49:09PM +0100, Marcus Comstedt wrote:
> I am planning to make devices and filesystems for the visual memories,
> but I haven't started on that yet.  Here's something to think about
> btw:  How should the minor device numbers work for the memory cards?
> You probably want to code in the port and slot number statically, so
> that a card in position B2 will always have the same device node for
> example.  So there are 4 ports and 6 slot numbers to code in.  What's
> more though is that each card can theoretically contain 256 partitions
> (although I haven't seen one with more partitions than 1; maybe this
> was intended for the Zip drive?).  This gives at least 6144 different
> minors.  But if I read the source correctly it looks like NetBSD can
> handle up to 1M minors, so I guess that won't be a problem.

Another thing to think about is that VMUs are easily shufflable around--
if you've got a particular VMU in your fstab (or the bsd equivalent; 
I'm not much of a BSD geek yet), you're going to want to mount it in
the same place and you're probably not going to want to remember which 
port of which controller you had it in. It might be a neat idea to 
assign a serial number to the thing when you make a filesystem on it
so you know which one it is. I keep thinking it would be really cool
to make that serial number be the device node, but that gets into 
some good chicken-and-egg stuff that, if there is a solution for it,
I don't have enough coffee in me right now to find it. 

On the other hand, the only OS I can think of that keeps track of this
sort of thing with _any_ device is Irix (note that I'm probably missing
something obvious), so perhaps the proper response is just "Heck with it,
the user can remember where he plugs it in, just like that SCA SCSI drive
on his Sparc." 

> So, maybe (partition*24)+(port*6)+slot?  Or is it better to have
> bitfields, like (partition*32)+(port*8)+slot?  Some other order?  (I
> think partition should go at the top anyway, since you'll only be
> using partition 0 in practice.)

Makes sense, but I suspect at the top you meant port*4. (4 ports, 6 slots.)

I'd go with the bitfield version-- you'll need 3 for the slot, 2 for the 
port, and 5 for the partition, which puts you still well shy of the million
mark. Having a few extra might be useful for future development (perhaps
Dreamcast 2 will have 8 controller ports?), so perhaps something more like
4 for the slot, 4 for the port, and the rest for partitions would be a 
better bet. Hm, or would having extras now get confusing? Is there a 
hardware spec for how many controller ports the console could support? 
(After all, it seems you can have 6 slots on a port even though you can 
only fit two memory modules in a normal controller...)

<lurk>, and perhaps it's not even worth real salt, make it shakers of 
potassium chloride.

-JDF
-- 
J.D. Forinash                           ,-.       
Georgia Tech College of Computing CNS  ( <  	  
211 CCB; (404)-385-0391                 `-'
The more you learn, the better your luck gets.