Re: [linuxdc-dev] VMU driver (Better maple)

[M. R. B. <mr...@0x...>]

* Fredrik Hubinette <hu...@hu...> on Sat, Jan 26, 2002:

>=20
> Any complaints about the new maple stuff so far?
> I've started reading up on block and mtd devices,
> and it seems to me that the mtd subsystem really
> isn't very well suited for writing a VMU driver.
>=20

I haven't had a chance to test anything, I'm still tied up with another
project, probably for another week.  I booted it a few times after I
committed your patch, I didn't run into any snags, except for the module
issue.

> In particular, the mtd subsystem seems to use driver api
> which writes one byte at a time, which is something
> I would really really like to avoid in a VMU driver.
>=20

Where did you see this?  That MTD couldn't handle block devices?

> In my oppinion it would seem better to use a block device
> driver, but this may have other traps of course.
> One particular issue with a VMU driver is that it needs
> to convey some meta-information (size, block size, root
> block location etc.) to the reader/filesystem. One way
> to support this would be to use an ioctl, but I'm not sure
> that would be the best way because then loopbacks would
> be impossible once a VMU filesystem is written.....
>=20

How is conveying metainformation different than any other block device in
existance?  I'm not sure I follow.  If you dd from a CD-ROM drive to a
file, you'll only get the size of that CD - the metainformation is
privately manipulated by the block driver itself.

> An alternative solution (which is not pretty, but it works)
> would be to map the meta-information into block 0 and then
> map block 0 of the VMU into block 1 of the block device
> (etc. etc.).
>=20

Map where?  I thought you ditched MTD :P.  Just kidding.  I'm not so sure
you want to give up on MTD, have you taken a look at the initial work Paul
has done in CVS? =20

> And, before I forget: If I do make a vmu driver, what major/minor
> numbers should I use? In theory you can connect 24 vmus to a
> dreamcast, so I'll need at least 24 separate devices. (Alternatively,
> I could create *one* device node which maps all the vmus into one
> address space, but I would only do that as a last resort...)
>=20

Hmm, check linux/Documentation/devices.txt for unused numbers.  You can
also use devfs - I'm not so sure on the API, but that documentation is in
the kernel tree as well.

> What do you people think? Since I'm fairly new to linux kernel
> hacking I apreciate your input on these ideas.

Paul had a pretty good bead on things, he'll probably reply with something
more intelligible than what I wrote here.

M. R.