From owner-freebsd-small Wed Oct 7 12:09:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25376 for freebsd-small-outgoing; Wed, 7 Oct 1998 12:09:21 -0700 (PDT) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25367 for ; Wed, 7 Oct 1998 12:09:18 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA01805 for ; Wed, 7 Oct 1998 12:14:32 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810071914.MAA01805@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-small@FreeBSD.ORG Subject: Re: Command-line i/f (Re: PicoBSD) In-reply-to: Your message of "Wed, 07 Oct 1998 11:30:07 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Oct 1998 12:14:32 -0700 From: Mike Smith Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > > > > > Extremely varied - I certainly see it being used on flash-based > > > > systems; don't get me wrong, I'd love to see an unencumberd TFFS clone. > > > > 8) > > > > > > Maybe we could give away our BIOS INT 13 FFS code and some kind > > > FreeBSD hacker could munge it into unix land... > > > > That'd be an excellent start. I take it that your FFS is proprietary > > (ie. it's not TFFS-compatible)? > > Yes, but compatibility for non-removeble media may not be so important... Indeed, and having something would be much better than having nothing. 8) Most of the removable media these days seems to be ATA-based anyway, with the FFS embedded in the device itself. > > I might be available to do this, but if not I'd be more than happy to > > help anyone that felt like undertaking the development of a generic > > flash covering layer. > > > > (It's not really a filesystem so much as a block manager, correct?) > > Right, just logical-physical sector remapping - statistical > erase-block/write-target ranking and maintaining erase block statistics in > a distributed way. Our method is fairly memory intensive (about 4K RAM per > M byte of drive) so mainly suited to smaller drives. It sounds like it would best be implemented as a covering layer which looks like a block device on top and uses a set of basic access primitives on the bottom to access the flash device itself. Hmm. Is your code in C or x86 assembler? Do you have (ready to hand) functional documentation on the on-chip data structures, etc.? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message