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

[Paul M. <pm...@mv...>]

On Sat, Jan 26, 2002 at 10:49:27PM -0800, Fredrik Hubinette wrote:
> > As far as sizes are concerned.. take a look at include/linux/mtd/map.h =
..
> >=20
> >         __u8 (*read8)(struct map_info *, unsigned long);
> >         __u16 (*read16)(struct map_info *, unsigned long);
> > 	__u32 (*read32)(struct map_info *, unsigned long);
> >=20
> > [snip]
> >=20
> >         void (*write8)(struct map_info *, __u8, unsigned long);
> >         void (*write16)(struct map_info *, __u16, unsigned long);
> >         void (*write32)(struct map_info *, __u32, unsigned long);
> >=20
> > So no .. in no way are you limited to 8-bit only access..
>=20
> None of these functions provide access to a whole block of data though,
> which is what would make most sense for a maple VMU device.
>=20
No, requests are dealt with in a manner that's MTD-sane. You aren't going to
be dealing with block-aligned requests in much of anything else either, so
there's really not much point in deviating from this.

In addition to this, maple isn't that fast, and 128k flash isn't that big. =
You
aren't going to run into much as far as an I/O bottleneck by breaking things
out into 8/16/32bit requests.

> Well, I'm planning on writing a user-space utility for reading/writing
> vmus first. That way I can make sure I have all the details right before
> I implement an actual filesystem. I need access to the actual device first
> though.
>=20
Okay. Well, you can try doing it through the block layer directly if you
really want.. but I think you're going to run into a lot more drawbacks this
way instead of going through MTD. Though since I likely won't be hacking on
the MTD driver in the next couple of days, you might wish to persue the blo=
ck
driver idea if you want something quick and dirty to get you to the point
where you can start hacking on the VMU fs.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.