This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ECOS] load data from floppy


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 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.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]