From owner-freebsd-mips@FreeBSD.ORG Mon Nov 22 14:57:16 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 046AE1065679 for ; Mon, 22 Nov 2010 14:57:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 849FF8FC19 for ; Mon, 22 Nov 2010 14:57:15 +0000 (UTC) Received: by wye20 with SMTP id 20so125158wye.13 for ; Mon, 22 Nov 2010 06:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=jaSpsfQ7C7lO8E0FjZWGO618PPHOTPJkjdpf4Tct4L8=; b=n8b85V/YMNdhG4Jmu1eqkiNsyJap6taQ4jw9+D6KDnGAeYoOI8bxY/jME6eJax8NnK k6GKN3JtbwOPgq8xCS8Rs5s+xtqHpNV4DzPASxelbX7B8xo57ExoO1ivtTCzrwNiRGXn amI4M36h550dDKthDJXZR0oHQvtCEUMY5Re9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=F/hs8ziztASxUQaFZqbNozllKCKs3wMrZOMOspNTYQIQCS7m6Dnow5+1XHK0TgpnSt dHVFKQxIrvUXA7wVy4k/c/Mes6Ln/dFUMMR9C5fTt2VlhmvV0DMorIN7S1yHsegk3fXD r80UhhB7Gs4A+NqGw2vAkbQ9/crGwVgc3y4e0= MIME-Version: 1.0 Received: by 10.216.191.210 with SMTP id g60mr5228367wen.5.1290437827384; Mon, 22 Nov 2010 06:57:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Mon, 22 Nov 2010 06:57:06 -0800 (PST) In-Reply-To: <20101122135703.1487660c.ray@dlink.ua> References: <201011191201.47230.freebsd-mips@dino.sk> <20101121155810.e615d4ad.ray@ddteam.net> <20101122135703.1487660c.ray@dlink.ua> Date: Mon, 22 Nov 2010 22:57:06 +0800 X-Google-Sender-Auth: 225lDTnya_RQOfPiF3eRp6y816A Message-ID: From: Adrian Chadd To: Alexandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksandr Rybalko , freebsd-mips@freebsd.org Subject: Re: First RSPRO deployed ! X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 14:57:16 -0000 On 22 November 2010 19:57, Alexandr Rybalko wrote: >>> Can you explain it a bit better? The idea is to not have the RW >>> offset/length hardcoded, it instead is based on whatever is left in >>> the partition after the RO LZMA section. > Ah, now I`m understand you. That possible with geom_map. [snip] > In that example GEOM_MAP setup 8 parts, > part called rootfs_ro is where lzma-ed rootfs live, > part called rootfs_rw is blank part for rw data. > GEOM_MAP search for keyword "--some-delimiter--" in flash from searchstart=0x00130000 with step 64k (searchstep="65536") > This require correct alignment of key. Right. The openwrt board config code has things like the above hard coded. I like the idea of having to above to list flash partitions but not to go grovelling through the flash partition to find 'filesystem markers'. :-) Anyway, that's personal preference. Whatever works, works. :) >>> The other thing to consider is what BIO_WRITE means. RIght now it's >>> effectively BIO_READ_OVERWRITE_WRITE - ie, the disk devices handle >>> this as "read in the underlying sector(s), modify what we need to, and >>> write out the results." This is a bit inefficient for flash devices. >>> It may be cleaner to add a new BIO for "flash writes" that have >>> flash-write semantics - ie, depending upon the flash device behaviour, >>> either bits get set 0->1 or they get set 1->0, but an ERASE is needed >>> to reset them. That then begs the question - what about >>> BIO_FLASH_ERASE? > > Good idea, but think we still need special FS for NOR like flash. We still do. The point is, all of the above work is to lay a foundation to let people experiment with "flash FSes". IMHO right now the entry barrier is too high: a flash fs author would have to invent an MTD layer as well as a flash filesystem layer. I'd rather we take care of a basic MTD layer - whether it be a GEOM extension or something else - and then open the floor to further experimenting. :) Adrian