From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-Boot, 1/3] sysboot: Add support for ubifs to the sysboot command
Date: Sat, 22 Aug 2015 20:04:55 +0200 [thread overview]
Message-ID: <55D8B9C7.6080206@redhat.com> (raw)
In-Reply-To: <55D79FD4.5010107@wwwdotorg.org>
Hi,
On 22-08-15 00:01, Stephen Warren wrote:
> On 08/21/2015 03:56 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 20-08-15 21:53, Stephen Warren wrote:
>>
>>
>> > On 20-08-15 18:04, Hans de Goede wrote:
>>>> ubifs does not go though the generic block layer because mtd devices
>>>> are special, so the "any" filesystem option to sysboot does not work,
>>>> this adds support for a "ubifs" filesystem to the sysboot command which
>>>> makes it possible to boot from ubifs using an extlinux.conf file.
>> >
>> > Why are they special? Surely ubifs support can be integrated into the
>> > filesystem layer, thus removing the need for patches 1 and 3 in this
>> series?
>>
>> I looked into that before going that root, the problem is that the
>> filesystem layer assumes that files sit on top of block devices,
>> and all the filesystem layer code operates on block_dev_desc_t devices.
>>
>> But ubifs operates on ubi volumes which in turn operate on raw nand,
>> this has vastly different characteristics then regular block devices.
>>
>> ubifs deals with erase-blocks, finding or creating a free
>> erase block when it needs to write stuff, then erasing an entire
>> block and writing part of it a page-size at a time where
>> erase-block-size != page-size, and both are typically of values
>> much larger then disk sector-sizes. There is no notion of erase
>> blocks in the fs / block layer.
>
> Can't the filesystem layer simply be taught how to look up block devices for most filesystems, but look up volumes for other filesystems? I still see no fundamental reason we can't abstract this so higher level SW doesn't have to have special cases.
Ok, so I've given this a second shot, and you are right, it is possible
to make ubifs work with the generic filesystem code.
I'll post a v2 using that.
Regards,
Hans
prev parent reply other threads:[~2015-08-22 18:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 16:04 [U-Boot] [PATCH 1/3] sysboot: Add support for ubifs to the sysboot command Hans de Goede
2015-08-20 16:04 ` [U-Boot] [PATCH 2/3] ubifs: Add a ubifsexists command Hans de Goede
2015-08-20 16:04 ` [U-Boot] [PATCH 3/3] distro_bootcmd: Add support for booting from ubifs Hans de Goede
2015-08-20 19:53 ` [U-Boot] [PATCH 1/3] sysboot: Add support for ubifs to the sysboot command Stephen Warren
2015-08-21 9:56 ` [U-Boot] [U-Boot, " Hans de Goede
2015-08-21 22:01 ` Stephen Warren
2015-08-22 18:04 ` Hans de Goede [this message]
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=55D8B9C7.6080206@redhat.com \
--to=hdegoede@redhat.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.