Re: [ECOS] load data from floppy

[Savin Zlobec <savin at torina dot fe dot uni-lj dot si>]

Gary Thomas <gary@mlbassoc.com> writes:
> On Wed, 2003-07-30 at 08:23, Nick Garnett wrote:
> > Gary Thomas <gary@mlbassoc.com> writes:
> >
> > > On Wed, 2003-07-30 at 04:36, Nick Garnett wrote:
> > > > davidw@dedasys.com (David N. Welton) writes:
> > > >
> > > > > Nick Garnett <nickg@ecoscentric.com> writes:
> > > > > >
> > > > > > > I'm having a go at making a floppy driver, but it doesn't appear
> > > > > > > to be particularly simple:-/
> > > > > >
> > > > > > I seem to recall that the PC floppy hardware is really nasty to
> > > > > > program. IDE is a doddle by comparison.
> > > > >
> > > > > You're right.  It's a very unpleasant interface.
> > > > >
> > > > > I managed to beat the relevant Minix code into shape to do what I
> > > > > need.  Would this be of any interest to you guys?  I'm sure it needs
> > > > > an expert hand to really bring it up to snuff, but it does work for
> > > > > reading a floppy.  The license is the new BSD-style Minix license.
> > > > >
> > > >
> > > > It would certainly be worth looking at. We also need to make sure that
> > > > way you are using it matches with the (currently very vague) ideas I
> > > > have about how block devices should work. There are also issues of
> > > > packaging, configuration and coding style to worry about.
> > > >
> > >
> > > Are any of these ideas written down?  I ask, in particular, because
> > > I may wish to implement some block I/O devices (and associated file
> > > systems) soon and I'd like to keep my approach in line with you.
> > >
> >
> > Nothing written I'm afraid. The main thing is the question of
> > addressing and transfer unit granularity. It's tempting to treat a
> > block device like a file and address and transfer on byte
> > granularity. But we need to deal with multi-GB drives, so that won't
> > work if we use a 32 bit offset. My intention was to work in 512 byte
> > sectors, giving a limit of 2TB for any single block device. I think
> > that should be adequate for most embedded needs.
> >
> > An alternative approach is to negotiate these parameters between the
> > filesystem and driver. But I would prefer to keep things simple.
> >
> > If you are going to do some filesystem work then we should make some
> > effort to coordinate things. We have already had a submission of a
> > simple FAT16 filesystem implementation, I have been working on a full
> > VFAT32 filesystem in spare moments (which have been few and far
> > between, so there has not been much progress), and I know that there
> > have been other efforts to port GPL code. If we are not careful we
> > will end up with several parallel efforts, and various annoyed
> > people.
>
> Indeed.  I've looked at the FAT16 code you mention above and while it
> seems pretty good, the big *missing* piece is the block device I/O.
> That would seem to be one of the first things that we'd have to design,
> outside of the file systems themselves.

I did some block I/O. It does just the position -> sector/offset
translation and calls the lower layer to read/write sectors. It
suffers from the 32 bit offset problem, but I was not particularly
concerned with it since I only need it to work with smaller CF cards.

One possible solution would be to set the sector number trough
the set_config interface. Then the pos parameter in bwrite/bread
would mean the position inside the current sector. In case of pos
exceeding the sector size we could increment the current sector
number accordingly - this would reduce the number of calls to
set_config in some cases. And by setting the current sector
number to 0 by default could simplify the interface for cases
where 32 bit offsets would be enough.

> I think your idea of reasonable sized sectors as the basic granularity
> is the right approach.  (512 bytes is OK, but maybe this should be
> configurable)  We also need to think about all the rest of the "driver"
> stuff like initialization, control, and maybe [shudder] a block cache.

I'am also working on a simple block cache - it is quite generic and
takes read/write block functions as argumets on create. It uses fixed
size memory pool for block memory management. Blocks are stored in
rbtree using block numbers as keys, also the list of blocks is keept
sorted by usage (from most to least recently used). When there is
no more memory for new block the least recently used block is
synced and its memory reused. The interface is simple and can be
used on filesystem level or block device level - well I'am just
talking from my needs point of view :-)

savin