From: Savin Zlobec <savin@elatec.si>
To: Alexander.Neundorf@jenoptik.com, andrew@lunn.ch
Cc: ecos-discuss@sources.redhat.com
Subject: [ECOS] Re: fatfs and io disk misc patches
Date: Fri, 09 Jul 2004 11:39:00 -0000 [thread overview]
Message-ID: <40EE83F0.40609@elatec.si> (raw)
Alexander Neundorf wrote:
> <>> > Since people are starting to use it and doing ports, it would be
> > > wise to specify how all of the disk subsystem should look and what
> > > features should be supported before it gets harder and harder to
> > > change anything generic.
> > >
> > > Now it is the time for users to post their comments,
> > feelings, wishes...
> >
> > Not many comments :-(
>
> Ok, wishes come here :-) :
> Faster cf access by checking for adjacent sectors, support for
> exchanging the cf card while<> ecos is running (or does it actually
> work and I was too stupid ?), long file names, fat32.
In my spare moments I did (doing) some refactoring on fatfs. File access
is faster, reduced memory usage,
saner code, kernel dependencies are gone, some traces of malloc left,
but shouldn't last long (maybe I'll make
an CDL option for that). After that I may go for the generic ATA low
level driver...
Hot exchanging the CF actually works - the disk_(dis)connected callbacks
are intended for that, they trigger
(in)validation of device handlers and MBR scanning. They are indended to
be called from the low level driver
which should detect the CF insertion/removal - or a pair of keys could
be defined for cyg_io_set_config which
would do this in disk_set_config. One may face the problem of unmounting
the fatfs after the CF was removed...
for this we would need an additional flag field in umount fn to specify
an forced unmount, or it could be specified
with fs_get/set_config.
About the adjacent sectors, long file names and fat32 - I wouldn't mind
having that - any volunteers ?
savin
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
next reply other threads:[~2004-07-09 11:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-09 11:39 Savin Zlobec [this message]
[not found] <40DA9B63.9000200@elatec.si>
[not found] ` <20040629163314.GH5877@lunn.ch>
[not found] ` <40E3DBF9.1060107@elatec.si>
[not found] ` <20040701103046.GB11101@lunn.ch>
[not found] ` <40E3F0FE.4070306@elatec.si>
[not found] ` <20040701130635.GD11101@lunn.ch>
[not found] ` <40E51E5D.8050708@elatec.si>
[not found] ` <20040702091532.GH11101@lunn.ch>
2004-07-02 12:44 ` Savin Zlobec
2004-07-08 10:30 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40EE83F0.40609@elatec.si \
--to=savin@elatec.si \
--cc=Alexander.Neundorf@jenoptik.com \
--cc=andrew@lunn.ch \
--cc=ecos-discuss@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).