From owner-freebsd-mips@FreeBSD.ORG Mon Nov 22 07:54:32 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 AC6071065670 for ; Mon, 22 Nov 2010 07:54:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEB18FC17 for ; Mon, 22 Nov 2010 07:54:31 +0000 (UTC) Received: by wwd20 with SMTP id 20so6775201wwd.31 for ; Sun, 21 Nov 2010 23:54:31 -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=2CXevff6Tld+uhykEv37WBVabCfQFtpMRn5taTy12zk=; b=OPlGdUzLNY4BV11c8m5lJoQYhU6DY8leIN+b60aSPJX0YDtrvQmIvim1JbSGU3i2wk i7Qx8mHbyv1UlqqymkWZiISxrkYHMAWIof9TxD1yGChkBHr2qObq4UC/FLq+HdtnSKaf FTEL/gVArFYED4/jeDf4nSmjU6PL2Orbe45Hs= 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=WfhUFzm05IbqDQ28VOQrNswpl8Ep/8N7C6nhDlIfmPEOHR/8bJpk7GhfZbmBfZ82kw I9FCCRyzq4l1/qvEE3GEj/L8CrLfyApwswIy8WXF196a0LIGzZ6fhDIS7kaqirNm2Lae njPpNk18VISIXGp86TELme3FBjjUHfKOEStrw= MIME-Version: 1.0 Received: by 10.216.157.6 with SMTP id n6mr4756619wek.35.1290412466065; Sun, 21 Nov 2010 23:54:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.65.210 with HTTP; Sun, 21 Nov 2010 23:54:25 -0800 (PST) In-Reply-To: <20101121155810.e615d4ad.ray@ddteam.net> References: <201011191201.47230.freebsd-mips@dino.sk> <20101121155810.e615d4ad.ray@ddteam.net> Date: Mon, 22 Nov 2010 15:54:25 +0800 X-Google-Sender-Auth: Udjbrn_u28IerMf2nDgKixOi954 Message-ID: From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Cc: 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 07:54:32 -0000 On 21 November 2010 21:58, Aleksandr Rybalko wrote: >> * aim to get geom_ulzma into the base :-) > No problem to add geom_ulzma into base, problem with lzma. > LZMA decoder currently stored in geom_ulzma.c, this one has style(9) > problems. > Another one decoder live in libarchive, this one inaccessible by > kernel. > So we need something middle, like zlib in kernel code (why it in net > subdir, but uses with many parts) Well, it may be possible to create a liblzma for the kernel, if someone's willing to do the legwork to tidy up the style(9) stuff. >> * modify it a bit so it exports two GEOM devices - a read-only device >> with the lzma'ed FS in it, and a read-write'able "rest"; > For what? > flash splited by parts by geom_map (old name geom_mtd, loos@ name > geom_flash IIRC), that parts rw, parts where stored ulzma compressed > data handled by GEOM_ULZMA, that RO. 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. > I also use small hack enabled writing for overlapped parts. > Biggest part named "upgrade" overlapped with "kernel" part and "rootfs", > so we can upgrade box when "kernel" and "rootfs" are opened. How do you overwrite "rootfs" if you're running from it? (Without remounting root into a ramdisk and upgrading, openwrt-style.) >> * modify GEOM to pass through disk parameters from the provider, so >> the flash device can export attributes (read size, write sizes, etc); >> * modify the flash driver to have a small default block size (say, 128 >> bytes) so small transactions don't require huge amounts of SPI bus >> access; > I use BS=4, since I know many devices that map their FS not to block > boundary. :( Yup. But I can't help but think BS=4 is going to be very inefficient for any FSes which do lots of small IO. 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? Adrian