* Re: Representing Embedded Architectures at the Kernel Summit
From: Mike Frysinger @ 2009-06-16 8:06 UTC (permalink / raw)
To: Mike Rapoport
Cc: James Bottomley, ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <4A373EE6.6070201@compulab.co.il>
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
> James Bottomley wrote:
>> We've got to the point where there are simply too many embedded
>> architectures to invite all the arch maintainers to the kernel summit.
>> So, this year, we thought we'd do embedded via topic driven invitations
>> instead. Â So what we're looking for is a proposal to discuss the issues
>> most affecting embedded architectures, or preview any features affecting
>> the main kernel which embedded architectures might need ... or any other
>> topics from embedded architectures which might need discussion or
>> debate.
>
> Another issue that affects embedded architectures is drivers initialization
> order. There are a lot of cases when you need the drivers to be initialized in
> particular order, and current initcalls scheme does not allow fine grained
> control for it.
example: device configuration information stored in i2c eeprom (i.e.
dimensions of attached framebuffer), but i2c is not available when
framebuffer layer is setup. framebuffer driver has to be built as a
module and loaded by userspace, or i2c information is read by
bootloader and passed down to the kernel.
-mike
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Mike Rapoport @ 2009-06-16 6:42 UTC (permalink / raw)
To: James Bottomley; +Cc: ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <1243956140.4229.25.camel@mulgrave.int.hansenpartnership.com>
James Bottomley wrote:
> Hi All,
>
> We've got to the point where there are simply too many embedded
> architectures to invite all the arch maintainers to the kernel summit.
> So, this year, we thought we'd do embedded via topic driven invitations
> instead. So what we're looking for is a proposal to discuss the issues
> most affecting embedded architectures, or preview any features affecting
> the main kernel which embedded architectures might need ... or any other
> topics from embedded architectures which might need discussion or
> debate.
Another issue that affects embedded architectures is drivers initialization
order. There are a lot of cases when you need the drivers to be initialized in
particular order, and current initcalls scheme does not allow fine grained
control for it.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 1/2] MMC Agressive clocking framework v2
From: Pierre Ossman @ 2009-06-15 19:09 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-arm-kernel, linux-embedded, Linus Walleij
In-Reply-To: <63386a3d0906020536t5a3391f9r921959ba6d6dd96e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4222 bytes --]
On Tue, 2 Jun 2009 14:36:28 +0200
Linus Walleij <linus.ml.walleij@gmail.com> wrote:
> This patch modified the MMC core code to optionally call the
> set_ios() operation on the driver with the clock frequency set
> to 0 to gate the hardware block clock (and thus the MCI clock)
> for an MMC host controller after a grace period of at least 8
> MCLK cycles. It is inspired by existing clock gating code found
> in the OMAP and Atmel drivers and brings this up to the host
> abstraction. Gating is performed before and after any MMC request
> or IOS operation, the other optional host operations will not
> ungate/gate the clock since they do not necessary touch the
> actual host controller hardware.
>
> It exemplifies by implementing this for the MMCI/PL180 MMC/SD
> host controller, but it should be simple to switch OMAP and
> Atmel over to using this instead.
>
> Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
> ---
This looks pretty good. We might want to make it more runtime
configurable in the future, but this lays a nice groundwork. It's also
nicely commented to boot. :)
The only thing that concerns me is the locking and reference counting.
Wouldn't it be sufficient to enable the clock around requests? Or
when the host lock is grabbed? Either version would remove the need for
both clk_users and clk_lock. I think it would also remove a lot of the
special logic you have.
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index ab37a6d..6ae2156 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -14,3 +14,14 @@ config MMC_UNSAFE_RESUME
> This option is usually just for embedded systems which use
> a MMC/SD card for rootfs. Most people should say N here.
>
> +config MMC_CLKGATE
> + bool "MMC host clock gaing (EXPERIMENTAL)"
> + depends on EXPERIMENTAL
> + help
> + This will attempt to agressively gate the clock to the MMC host,
> + which typically also will gate the MCI clock to the card. This
> + is done to save power due to gating off the logic and bus noise
> + when MMC is not in use. Your host driver has to support this in
> + order for it to be of any use.
The last sense isn't true anymore, is it?
> +
> + Of unsure, say N.
"If" :)
> +/*
> + * Internal work. Work to disable the clock at some later point.
> + */
> +static void mmc_clk_disable_work(struct work_struct *work)
> +{
> + struct mmc_host *host = container_of(work, struct mmc_host,
> + clk_disable_work);
> +
> + mmc_clk_disable_delayed(host);
> +}
I think I did a bad job explaining my comments about this the last
time. What I was trying to say was that why have this
mmc_clk_disable_work() when you could give mmc_clk_disable_delayed()
directly to the workqueue?
> +/*
> + * mmc_clk_remove - shut down clock gating code
> + * @host: host with potential hardware clock to control
> + */
> +static inline void mmc_clk_remove(struct mmc_host *host)
> +{
> + if (cancel_work_sync(&host->clk_disable_work))
> + mmc_clk_disable_delayed(host);
> + BUG_ON(host->clk_users > 0);
> +}
I'm not sure why you call mmc_clk_disable_delayed() here. Is the clock
properly enabled again when this function exits? It should be, but the
disable call there has me confused.
> @@ -80,6 +235,8 @@ struct mmc_host *mmc_alloc_host(int extra, struct
> device *dev)
> host->class_dev.class = &mmc_host_class;
> device_initialize(&host->class_dev);
>
> + mmc_clk_alloc(host);
> +
> spin_lock_init(&host->lock);
> init_waitqueue_head(&host->wq);
> INIT_DELAYED_WORK(&host->detect, mmc_rescan);
> @@ -156,6 +313,8 @@ void mmc_remove_host(struct mmc_host *host)
> device_del(&host->class_dev);
>
> led_trigger_unregister_simple(host->led);
> +
> + mmc_clk_remove(host);
> }
>
> EXPORT_SYMBOL(mmc_remove_host);
alloc and remove don't form a nice pair. I suggest add/remove or
perhaps init/exit.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Tim Bird @ 2009-06-15 17:58 UTC (permalink / raw)
To: Marco; +Cc: Linux FS Devel, Linux Embedded, linux-kernel, Daniel Walker
In-Reply-To: <4A36887C.1050906@gmail.com>
Marco wrote:
> Tim Bird wrote:
>> Marco wrote:
>>> This is a second attempt at mainlining Pramfs. The first attempt was
>>> back in early 2004 by MontaVista. Since then the kernel code has almost
>>> been completely rewritten. So my first item on the list was porting the
>>> code on a recent kernel version. After that I added the XIP support.
>> It's very nice to see this technology revived.
>>
>> Is the information at:
>> http://pramfs.sourceforge.net/
>> and
>> http://pramfs.sourceforge.net/pramfs-spec.html
>> still valid - particularly the latter?
>
> Yep. at 99%. I've done some modifications due to the porting and there
> will be some ones due to this review. I tried to talk with Steve
> Longerbeam to update the site but without success. I'd like to update it.
>
>> It would be very nice to see this get mainlined. I believe that
>> one of the main uses for this is to store crash information
>> over a reboot so the next kernel (not in crashing state) can have
>> a better chance of dealing with it. As such, I think
>> it's important to keep the code paths for Pramfs short, synchronous,
>> and unentangled with other kernel systems (block IO, page cache, etc.).
>>
>
> Yes, I quite agree. I think that this kind of feature would be very
> useful especially for the embedded world.
Just FYI - we have an "exception monitor" at Sony
which is used in several projects, that records application and
kernel crash information into the file system, for subsequent
(often in-field) analysis. However, the data currently gets written
to a flash filesystem and the logs sometimes get truncated or otherwise
corrupted. This seems like a perfect match for what we're trying
to do.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-15 17:44 UTC (permalink / raw)
To: Tim Bird; +Cc: Linux FS Devel, Linux Embedded, linux-kernel, Daniel Walker
In-Reply-To: <4A3681C2.5010508@am.sony.com>
Tim Bird wrote:
> Marco wrote:
>> This is a second attempt at mainlining Pramfs. The first attempt was
>> back in early 2004 by MontaVista. Since then the kernel code has almost
>> been completely rewritten. So my first item on the list was porting the
>> code on a recent kernel version. After that I added the XIP support.
>
> It's very nice to see this technology revived.
>
> Is the information at:
> http://pramfs.sourceforge.net/
> and
> http://pramfs.sourceforge.net/pramfs-spec.html
> still valid - particularly the latter?
Yep. at 99%. I've done some modifications due to the porting and there
will be some ones due to this review. I tried to talk with Steve
Longerbeam to update the site but without success. I'd like to update it.
>
> It would be very nice to see this get mainlined. I believe that
> one of the main uses for this is to store crash information
> over a reboot so the next kernel (not in crashing state) can have
> a better chance of dealing with it. As such, I think
> it's important to keep the code paths for Pramfs short, synchronous,
> and unentangled with other kernel systems (block IO, page cache, etc.).
>
Yes, I quite agree. I think that this kind of feature would be very
useful especially for the embedded world.
Marco
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-15 17:42 UTC (permalink / raw)
To: Bryan Henderson
Cc: Artem Bityutskiy, Daniel Walker, Jamie Lokier, Linux Embedded,
Linux FS Devel, Linux Kernel
In-Reply-To: <OFD1325B2C.7A926EF9-ON882575D6.00567314-882575D6.00571BC3@us.ibm.com>
Bryan Henderson wrote:
>> Marco wrote:
>>> To enable direct
>>> I/O at all times for all regular files requires either that
>>> applications be modified to include the O_DIRECT flag on all file
>>> opens, or that a new filesystem be used that always performs direct
>>> I/O by default."
>> This could be done as well by just introducing a "direct_io_only"
>> mount option to a file-system which would need this feature.
>
> But it's possible that there's just no advantage to having a block device
> in the stack here. When unix block devices were invented, their main
> purpose was that they could reorder reads and writes and do buffering and
> caching -- all things essential for disk drives. We don't want to stretch
> the concept too far.
>
Yes I agree, we can't in this case talk about read and write reordering,
buffering and caching because we're talking about something completely
different from a classic disk. The issues of this kind of fs are more
similar to the tmpfs issues.
Marco
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Tim Bird @ 2009-06-15 17:15 UTC (permalink / raw)
To: Marco; +Cc: Linux FS Devel, Linux Embedded, linux-kernel, Daniel Walker
In-Reply-To: <4A33A7A2.1050608@gmail.com>
Marco wrote:
> This is a second attempt at mainlining Pramfs. The first attempt was
> back in early 2004 by MontaVista. Since then the kernel code has almost
> been completely rewritten. So my first item on the list was porting the
> code on a recent kernel version. After that I added the XIP support.
It's very nice to see this technology revived.
Is the information at:
http://pramfs.sourceforge.net/
and
http://pramfs.sourceforge.net/pramfs-spec.html
still valid - particularly the latter?
It would be very nice to see this get mainlined. I believe that
one of the main uses for this is to store crash information
over a reboot so the next kernel (not in crashing state) can have
a better chance of dealing with it. As such, I think
it's important to keep the code paths for Pramfs short, synchronous,
and unentangled with other kernel systems (block IO, page cache, etc.).
Thanks,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Bryan Henderson @ 2009-06-15 15:51 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: Daniel Walker, Jamie Lokier, Linux Embedded, Linux FS Devel,
Linux Kernel, Marco
In-Reply-To: <4A34DA30.1080201@gmail.com>
> Marco wrote:
> > To enable direct
> > I/O at all times for all regular files requires either that
> > applications be modified to include the O_DIRECT flag on all file
> > opens, or that a new filesystem be used that always performs direct
> > I/O by default."
>
> This could be done as well by just introducing a "direct_io_only"
> mount option to a file-system which would need this feature.
A mount option would not be the right way. Mount options are for things
that are characteristic of the way you're going to access the files.
_This_ is a characteristic of the block device. So if one were to make
this memory accessible with a block device, it would make more sense to
have a block device ioctl. And it wouldn't ask the question, "should I
use direct I/O only," but "does this device have the performance
characteristics of a classic disk drive?"
But it's possible that there's just no advantage to having a block device
in the stack here. When unix block devices were invented, their main
purpose was that they could reorder reads and writes and do buffering and
caching -- all things essential for disk drives. We don't want to stretch
the concept too far.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Storage Systems
^ permalink raw reply
* Re: AT91SAM9G20 design and boot times
From: Marc Pignat @ 2009-06-15 6:32 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Nicolas Ferre, Aras Vaichas, linux-embedded
In-Reply-To: <20090612140626.GA10372@game.jcrosoft.org>
Hi all!
> if the boottime is critical I'll recommend you NOR + XIP
Nak, please have a look at "interest in XIP? - boot time benchmarks"
(http://marc.info/?l=linux-arm-kernel&m=117198517723134&w=2)
But in brief : the kernel is started faster with xip, but is so slow that it
will end booting after the non-xip kernel.
NOR flash bandwidth is *very* slow compared to SDRAM.
Best regards
Marc
^ permalink raw reply
* Re: Kernel crashing and log buffers...
From: Robin Getz @ 2009-06-14 18:33 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Russell King, Mike Frysinger, Greg Ungerer, Paul Mundt, Tim Bird,
Grant Erickson, linux-embedded
In-Reply-To: <20090613185926.BAB66832E416@gemini.denx.de>
On Sat 13 Jun 2009 14:59, Wolfgang Denk pondered:
> Dear Russell King,
>
> In message <20090613102642.GB7976@flint.arm.linux.org.uk> you wrote:
> >
> > The other way I've seen people read out crash messages is using a
> > debugger to dump the kernel's log buffer directly. That seems to work
> > as well as any other method, and has the advantage that it doesn't
> > require any kernel modifications.
>
> This works well in the lab during hardware bringup or BSP development.
>
> But we are also interested in a solution that allows to get more or
> less automatic access to the log buffer content after a crash - when
> you have several ten thousand systems in the field, such a feature
> can save you a lot of money.
in this case - is it true that providing the kernel crash log buffer to the
next running kernel - is actually more important than just giving it to the
bootloader? (Since the bootloader may not have the facilities to
email/post/netcat it to a developer - like the next running kernel might?)
In this case - the Bootloader being able to read the buffer, understand that
there was a crash, and be able to pass the buffer (with the crash message)
into the next running kernel - where that kernel can package it up and do
anything it wants to it - would be a requirement?
-Robin
^ permalink raw reply
* Re: [PATCH 04/14] Pramfs: Mounting as root filesystem
From: Marco @ 2009-06-14 16:29 UTC (permalink / raw)
To: Marco
Cc: David Woodhouse, Arnd Bergmann, Linux FS Devel, Linux Embedded,
Linux Kernel, Daniel Walker
In-Reply-To: <4A351FB0.3060008@gmail.com>
David Woodhouse wrote:
> On Sun, 2009-06-14 at 10:21 +0200, Marco wrote:
>> Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works
>> in memory. We could simply use /dev/null (there was an error in the
>> submitted kconfig description, my intention was to use /dev/mem). In
>> that case I can use UNNAMED_MAJOR. PRAMFS root option is not enabled
>> if it's already enabled the NFS one. What do you think?
>
> Why use a major number at all? See how we handle mtd and ubi devices in
> prepare_namespace() -- can't you do something similar?
>
Do you suggest me something similar? Why not. I though that mtd and ubi
were only special cases.
if (saved_root_name[0]) {
root_device_name = saved_root_name;
if (!strncmp(root_device_name, "mtd", 3) ||
!strncmp(root_device_name, "ubi", 3) ||
--------> !strncmp(root_device_name, "pram", 4)) {
mount_block_root(root_device_name, root_mountflags);
goto out;
}
ROOT_DEV = name_to_dev_t(root_device_name);
if (strncmp(root_device_name, "/dev/", 5) == 0)
root_device_name += 5;
}
^ permalink raw reply
* Re: [PATCH 04/14] Pramfs: Mounting as root filesystem
From: Marco @ 2009-06-14 16:05 UTC (permalink / raw)
To: David Woodhouse
Cc: Arnd Bergmann, Linux FS Devel, Linux Embedded, Linux Kernel,
Daniel Walker
In-Reply-To: <1244970445.3468.2732.camel@macbook.infradead.org>
David Woodhouse wrote:
> On Sun, 2009-06-14 at 10:21 +0200, Marco wrote:
>> Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works
>> in memory. We could simply use /dev/null (there was an error in the
>> submitted kconfig description, my intention was to use /dev/mem). In
>> that case I can use UNNAMED_MAJOR. PRAMFS root option is not enabled
>> if it's already enabled the NFS one. What do you think?
>
> Why use a major number at all? See how we handle mtd and ubi devices in
> prepare_namespace() -- can't you do something similar?
>
I can look at it.
Marco
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-14 16:04 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <20090614114613.GC9514@shareable.org>
Jamie Lokier wrote:
> Marco wrote:
>> Simply because the ramdisk was not designed to work in a persistent
>> environment.
>
> One thing with persistent RAM disks is you _really_ want it to be
> robust if the system crashes for any reason while it is being
> modified. The last thing you want is to reboot, and find various
> directories containing configuration files or application files have
> been corrupted or disappeared as a side effect of writing something else.
>
> That's one of the advantages of using a log-structured filesystem such
> as Nilfs, JFFS2, Logfs, UBIFS, Btrfs, ext3, reiserfs, XFS or JFS on a
> ramdisk :-)
>
> Does PRAMFS have this kind of robustness?
There's the checksum, but the most important feature of this fs is the
write protection. The page table entries that map the
backing-store RAM are normally marked read-only. Write operations into
the filesystem temporarily mark the affected pages as writeable, the
write operation is carried out with locks held, and then the pte is
marked read-only again. This feature provides protection against
filesystem corruption caused by errant writes into the RAM due to
kernel bugs for instance. I provided a test module for this. When the
module is loaded tries to do a dirty write in the superblock, at this
point you should see an error on the write.
>
>> In addition this kind of filesystem has been designed to work not
>> only with classic ram. You can think at the situation where you have
>> got an external SRAM with a battery for example. With it you can
>> "remap" in an easy way the SRAM. Moreover there's the issue of
>> memory protection that this filesystem takes care. > Why is an
>> entire filesystem needed, instead of simply a block driver > if the
>> ramdisk driver cannot be used? > >From documentation: "A relatively
>> straight-forward solution is to write a simple block driver for the
>> non-volatile RAM, and mount over it any disk-based filesystem such
>> as ext2/ext3, reiserfs, etc. But the disk-based fs over
>> non-volatile RAM block driver approach has some drawbacks:
>>
>> 1. Disk-based filesystems such as ext2/ext3 were designed for
>> optimum performance on spinning disk media, so they implement
>> features such as block groups, which attempts to group inode data
>> into a contiguous set of data blocks to minimize disk seeking when
>> accessing files. For RAM there is no such concern; a file's data
>> blocks can be scattered throughout the media with no access speed
>> penalty at all. So block groups in a filesystem mounted over RAM
>> just adds unnecessary complexity. A better approach is to use a
>> filesystem specifically tailored to RAM media which does away with
>> these disk-based features. This increases the efficient use of
>> space on the media, i.e. more space is dedicated to actual file data
>> storage and less to meta-data needed to maintain that file data.
>
> All true, I agree. RAM-based databases use different structures to
> disk-based databases for the same reasons.
>
> Isn't there any good RAM-based filesystem already? Some of the flash
> filesystems and Nilfs seem promising, using fake MTD with a small
> erase size. All are robust on crashes.
>
Good question. The only similar thing that I know it's a patch called
pmem provided by WindRiver. It's the main reason that I led to develop
this kind of fs. In addition in my projects to have this feature has
always been very useful.
>> However direct I/O has to be enabled at every file open. To
>> enable direct I/O at all times for all regular files requires
>> either that applications be modified to include the O_DIRECT flag
>> on all file opens, or that a new filesystem be used that always
>> performs direct I/O by default."
>
> There are other ways to include the O_DIRECT flag automatically. A
> generic mount option would be enough. I've seen other OSes with such
> an option. That code for that would be tiny.
>
> But standard O_DIRECT direct I/O doesn't work for all applications: it
> has to be aligned: device offset, application memory address and size
> all have to be aligned.
>
> (It would be a nice touch to produce a generic mount option
> o_direct_when_possible, which turns on direct I/O but permits
> unaligned I/O. That could be used with all applications.)
>
> As you say PRAMFS can work with special SRAMs needing memory
> protection (and maybe cache coherence?), if you mmap() a file does it
> need to use the page cache then? If so, do you have issues with
> coherency between mmap() and direct read/write?
See my response above about my concept of protection. However the mmap
it's a similar approach. I can "mmap" the SRAM and I can write into it
my data, but I think the possibility to have a fs it's great. We can use
the device as normal disk, i.e. we can use cp, mv and so on.
>
>> On this point I'd like to hear other embedded guys.
>
> As one, I'd like to say if it can checksum the RAM at boot as well,
> then I might like to use a small one in ordinary SRAM (at a fixed
> reserved address) for those occasions when a reboot happens
> (intentional or not) and I'd like to pass a little data to the next
> running kernel about why the reboot happened, without touching flash
> every time.
>
> -- Jamie
>
Yeah Jamie, the goal of this fs is exactly that!
Marco
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Jamie Lokier @ 2009-06-14 11:46 UTC (permalink / raw)
To: Marco; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <4A34A394.5040509@gmail.com>
Marco wrote:
> Simply because the ramdisk was not designed to work in a persistent
> environment.
One thing with persistent RAM disks is you _really_ want it to be
robust if the system crashes for any reason while it is being
modified. The last thing you want is to reboot, and find various
directories containing configuration files or application files have
been corrupted or disappeared as a side effect of writing something else.
That's one of the advantages of using a log-structured filesystem such
as Nilfs, JFFS2, Logfs, UBIFS, Btrfs, ext3, reiserfs, XFS or JFS on a
ramdisk :-)
Does PRAMFS have this kind of robustness?
> In addition this kind of filesystem has been designed to work not
> only with classic ram. You can think at the situation where you have
> got an external SRAM with a battery for example. With it you can
> "remap" in an easy way the SRAM. Moreover there's the issue of
> memory protection that this filesystem takes care. > Why is an
> entire filesystem needed, instead of simply a block driver > if the
> ramdisk driver cannot be used? > >From documentation: "A relatively
> straight-forward solution is to write a simple block driver for the
> non-volatile RAM, and mount over it any disk-based filesystem such
> as ext2/ext3, reiserfs, etc. But the disk-based fs over
> non-volatile RAM block driver approach has some drawbacks:
>
> 1. Disk-based filesystems such as ext2/ext3 were designed for
> optimum performance on spinning disk media, so they implement
> features such as block groups, which attempts to group inode data
> into a contiguous set of data blocks to minimize disk seeking when
> accessing files. For RAM there is no such concern; a file's data
> blocks can be scattered throughout the media with no access speed
> penalty at all. So block groups in a filesystem mounted over RAM
> just adds unnecessary complexity. A better approach is to use a
> filesystem specifically tailored to RAM media which does away with
> these disk-based features. This increases the efficient use of
> space on the media, i.e. more space is dedicated to actual file data
> storage and less to meta-data needed to maintain that file data.
All true, I agree. RAM-based databases use different structures to
disk-based databases for the same reasons.
Isn't there any good RAM-based filesystem already? Some of the flash
filesystems and Nilfs seem promising, using fake MTD with a small
erase size. All are robust on crashes.
> 2. If the backing-store RAM is comparable in access speed to system
> memory, there's really no point in caching the file I/O data in the
> page cache.
>
> Better to move file data directly between the user buffers
> and the backing store RAM, i.e. use direct I/O. This prevents the
> unnecessary populating of the page cache with dirty pages.
Good idea.
> However direct I/O has to be enabled at every file open. To
> enable direct I/O at all times for all regular files requires
> either that applications be modified to include the O_DIRECT flag
> on all file opens, or that a new filesystem be used that always
> performs direct I/O by default."
There are other ways to include the O_DIRECT flag automatically. A
generic mount option would be enough. I've seen other OSes with such
an option. That code for that would be tiny.
But standard O_DIRECT direct I/O doesn't work for all applications: it
has to be aligned: device offset, application memory address and size
all have to be aligned.
(It would be a nice touch to produce a generic mount option
o_direct_when_possible, which turns on direct I/O but permits
unaligned I/O. That could be used with all applications.)
As you say PRAMFS can work with special SRAMs needing memory
protection (and maybe cache coherence?), if you mmap() a file does it
need to use the page cache then? If so, do you have issues with
coherency between mmap() and direct read/write?
> On this point I'd like to hear other embedded guys.
As one, I'd like to say if it can checksum the RAM at boot as well,
then I might like to use a small one in ordinary SRAM (at a fixed
reserved address) for those occasions when a reboot happens
(intentional or not) and I'd like to pass a little data to the next
running kernel about why the reboot happened, without touching flash
every time.
-- Jamie
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Artem Bityutskiy @ 2009-06-14 11:08 UTC (permalink / raw)
To: Marco
Cc: Jamie Lokier, Linux Embedded, Linux Kernel, Linux FS Devel,
Daniel Walker
In-Reply-To: <4A34A394.5040509@gmail.com>
Marco wrote:
> To enable direct
> I/O at all times for all regular files requires either that
> applications be modified to include the O_DIRECT flag on all file
> opens, or that a new filesystem be used that always performs direct
> I/O by default."
This could be done as well by just introducing a "direct_io_only"
mount option to a file-system which would need this feature.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 04/14] Pramfs: Mounting as root filesystem
From: David Woodhouse @ 2009-06-14 9:07 UTC (permalink / raw)
To: Marco
Cc: Arnd Bergmann, Linux FS Devel, Linux Embedded, Linux Kernel,
Daniel Walker
In-Reply-To: <4A34B2FD.20701@gmail.com>
On Sun, 2009-06-14 at 10:21 +0200, Marco wrote:
>
> Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works
> in memory. We could simply use /dev/null (there was an error in the
> submitted kconfig description, my intention was to use /dev/mem). In
> that case I can use UNNAMED_MAJOR. PRAMFS root option is not enabled
> if it's already enabled the NFS one. What do you think?
Why use a major number at all? See how we handle mtd and ubi devices in
prepare_namespace() -- can't you do something similar?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH 04/14] Pramfs: Mounting as root filesystem
From: Marco @ 2009-06-14 8:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linux FS Devel, Linux Embedded, Linux Kernel, Daniel Walker
In-Reply-To: <200906140104.43463.arnd@arndb.de>
Arnd Bergmann wrote:
> On Saturday 13 June 2009, Marco wrote:
>> void __init mount_root(void)
>> {
>> +#ifdef CONFIG_ROOT_PRAMFS
>> + if (MAJOR(ROOT_DEV) == MEM_MAJOR) {
>> + if (mount_pramfs_root())
>> + return;
>> +
>> + printk(KERN_ERR "VFS: Unable to mount root fs via PRAMFS, trying floppy.\n");
>> + ROOT_DEV = Root_FD0;
>> + }
>> +#endif
>
> AFAICT, this will prevent booting from /dev/ram0 with a regular file system,
> because that also uses MAJOR(ROOT_DEV) == 1.
>
> Arnd <><
>
Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works
in memory. We could simply use /dev/null (there was an error in the
submitted kconfig description, my intention was to use /dev/mem). In
that case I can use UNNAMED_MAJOR. PRAMFS root option is not enabled if
it's already enabled the NFS one. What do you think?
Marco
^ permalink raw reply
* Re: [PATCH 14/14] Pramfs: XIP operations
From: Marco @ 2009-06-14 7:16 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <20090613140647.GD30053@uranus.ravnborg.org>
Sam Ravnborg wrote:
> On Sat, Jun 13, 2009 at 03:23:13PM +0200, Marco wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> XIP operations.
>>
>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>> ---
>>
>> diff -uprN linux-2.6.30-orig/fs/pramfs/xip.c linux-2.6.30/fs/pramfs/xip.c
>> --- linux-2.6.30-orig/fs/pramfs/xip.c 1970-01-01 01:00:00.000000000 +0100
>> +++ linux-2.6.30/fs/pramfs/xip.c 2009-06-13 12:54:26.000000000 +0200
>> @@ -0,0 +1,90 @@
>> +/*
>> + * FILE NAME fs/pramfs/xip.c
>> + *
>> + * BRIEF DESCRIPTION
>> + *
>> + * XIP operations.
>> + *
>> + * Copyright 2009 Marco Stornelli <marco.stornelli@gmail.com>
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#include <linux/mm.h>
>> +#include <linux/fs.h>
>> +#include <linux/genhd.h>
>> +#include <linux/buffer_head.h>
>> +#include "pram_fs.h"
>> +#include "xip.h"
>> +
>> +static int pram_find_and_alloc_blocks(struct inode *inode, sector_t iblock,
>> + sector_t *data_block, int create)
>> +{
>> + int err = -EIO;
>> + off_t block;
>> +
>> + lock_kernel();
>
> Can we find other solutions than taking the BKL?
> We are trying to get rid of it.
>
I know. It wasn't my intention to introduce it but as I said in my first
patch I've done a porting of this code from 2.6.10 and to remove it I
need time to analyze well the code to avoid deadlock and so on. If
someone would like to help me I'd really appreciate it. However I see
the use of BKL even in other recent "mainlined" fs as ext4, so I
preferred to move the porting effort on other areas. However it's the
first item on my todo list.
^ permalink raw reply
* Re: [PATCH 08/14] Pramfs: Makefile and Kconfig
From: Marco @ 2009-06-14 7:16 UTC (permalink / raw)
To: Daniel Walker; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel
In-Reply-To: <1244901732.5982.221.camel@desktop>
Daniel Walker wrote:
> On Sat, 2009-06-13 at 15:22 +0200, Marco wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> Makefile and Kconfig.
>>
>> Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
>> ---
>>
>
> You should move this patch to 11 of 14, as I think that is the point
> when the filesystem can actually be enabled and function. If this series
> is only applied up to this patch you can get build failures if you
> enabled PRAMFS, XIP, or any of the other features. Also breaking out the
> individual features menuconfig options like XIP, and write protect, etc,
> into their respective patches would be nice.
>
> Daniel
>
>
Ok Daniel thanks for your comments. Actually I split the patches by
functionality because I think that for this series it's a little bit
complicated to follow a sequence so as not to have building failure but
I can try. I think the only part I can split is the XIP. I think there
will be a lot of comments so I'll wait for other comments before to
re-submit other patches.
Marco
^ permalink raw reply
* Re: [PATCH 08/14] Pramfs: Makefile and Kconfig
From: Marco @ 2009-06-14 7:15 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <20090613135604.GB30053@uranus.ravnborg.org>
Sam Ravnborg wrote:
>> +
>> +config PRAMFS_NOWP
>> + bool "Disable PRAMFS write protection"
>> + depends on PRAMFS
>> + default n
>> + help
>> + Say Y here to disable the write protect feature of PRAMFS.
> n is default so "default n" is not needed.
> If you reverse the logic (and add a default y) then..
>
>> +ifneq ($(CONFIG_PRAMFS_NOWP),y)
>> +pramfs-objs += wprotect.o
>> +endif
> This is a trivial:
> pramfs-$(PRAMFS_WRITE_PROTECT) += wprotect.o
>
> (I renamed the option to something more descriptive - please do so in the abvoe).
>
>
>> +++ linux-2.6.30/fs/pramfs/Makefile 2009-04-19 11:58:51.000000000 +0200
>> @@ -0,0 +1,13 @@
>> +#
>> +# Makefile for the linux pram-filesystem routines.
>> +#
>> +
>> +obj-$(CONFIG_PRAMFS) += pramfs.o
>> +obj-$(CONFIG_TEST_MODULE) += pramfs_test.o
>> +
>> +pramfs-objs := balloc.o dir.o file.o inode.o namei.o super.o symlink.o
>
> Use:
> pramfs-y := balloc.o ...
>
> This match usa later in this file.
>
>> +
>> +ifneq ($(CONFIG_PRAMFS_NOWP),y)
>> +pramfs-objs += wprotect.o
>> +endif
>> +pramfs-$(CONFIG_PRAMFS_XIP) += xip.o
>
>
> Sam
>
Ok, thanks.
Marco
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Marco @ 2009-06-14 7:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Sam Ravnborg, Linux FS Devel, Linux Embedded, Linux Kernel,
Daniel Walker
In-Reply-To: <200906140059.57362.arnd@arndb.de>
Arnd Bergmann wrote:
> On Saturday 13 June 2009, Sam Ravnborg wrote:
>>> + union {
>>> + struct {
>>> + /*
>>> + * ptr to row block of 2D block pointer array,
>>> + * file block #'s 0 to (blocksize/4)^2 - 1.
>>> + */
>>> + off_t row_block;
>> It is my understanding that we shall use: __kernel_off_t
>> in exported headers.
>
> That is a correct understanding in general, however this case is
> different, because it describes an on-disk data structure,
> not a kernel to user space interface. Here, __kernel_off_t is just
> as wrong as off_t, because it will differ between 32 and 64 bit
> architectures, making the fs layout incompatible. I'd suggest
> simply defining this as __u64.
>
> Moreover, file system layout should be described in terms of
> big-endian or little-endian types (e.g. __be64 or __le64),
> together with the right accessor functions.
>
> Arnd <><
>
Yep, you're right. I have to change the definition to be compatible
between 32 and 64 bit archs.
Marco
^ permalink raw reply
* Re: [PATCH 06/14] Pramfs: Include files
From: Marco @ 2009-06-14 7:15 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linux FS Devel, Linux Embedded, Linux Kernel, Daniel Walker
In-Reply-To: <20090613140459.GC30053@uranus.ravnborg.org>
Sam Ravnborg wrote:
> On Sat, Jun 13, 2009 at 03:21:48PM +0200, Marco wrote:
>> From: Marco Stornelli <marco.stornelli@gmail.com>
>>
>> +#include <linux/types.h>
>> +
>> +#ifdef __KERNEL__
>> +#include <linux/sched.h>
>> +#include <linux/buffer_head.h>
>> +#include "pram_fs_sb.h"
>> +#endif
>
> The only reason to have this header file in include/linux/
> is that it is used by userspace.
> So please split it up so we have one header suitable for exporting
> and another header with all the promfs local stuff.
> The latter should be in fs/pramsfs/
Yeah you're right. Actually it's not used by userspace so I think I can
remove the ifdef.
>
>
>> +
>> +
>> +/*
>> + * Debug code
>> + */
>> +#ifdef __KERNEL__
>> +#define PFX "pramfs"
>> +#ifdef PRAMFS_DEBUG
>> +#define pram_dbg(format, arg...) \
>> + printk(KERN_DEBUG PFX ": " format , ## arg)
>> +#else
>> +#define pram_dbg(format, arg...) do {} while (0)
>> +#endif
>> +#define pram_err(format, arg...) \
>> + printk(KERN_ERR PFX ": " format , ## arg)
>> +#define pram_info(format, arg...) \
>> + printk(KERN_INFO PFX ": " format , ## arg)
>> +#define pram_warn(format, arg...) \
>> + printk(KERN_WARNING PFX ": " format , ## arg)
>> +#endif
>
> For a typical drivers we have some pr_* to avoid the above.
> Can they be used for a filesystem too?
Ok, I'll use them.
>
>> +
>> +/*
>> + * The PRAM file system magic number
>> + */
>> +#define PRAM_SUPER_MAGIC 0xEFFA
>
> Move to include/linux/magic.h
>
Ok.
>> +
>> +/*
>> + * Structure of an inode in PRAMFS
>> + */
>> +struct pram_inode {
>> + __u32 i_sum; /* checksum of this inode */
>> + __u32 i_uid; /* Owner Uid */
>> + __u32 i_gid; /* Group Id */
>> + __u16 i_mode; /* File mode */
>> + __u16 i_links_count; /* Links count */
>> + __u32 i_blocks; /* Blocks count */
>> + __u32 i_size; /* Size of data in bytes */
>> + __u32 i_atime; /* Access time */
>> + __u32 i_ctime; /* Creation time */
>> + __u32 i_mtime; /* Modification time */
>> + __u32 i_dtime; /* Deletion Time */
>> +
>> + union {
>> + struct {
>> + /*
>> + * ptr to row block of 2D block pointer array,
>> + * file block #'s 0 to (blocksize/4)^2 - 1.
>> + */
>> + off_t row_block;
>
> It is my understanding that we shall use: __kernel_off_t
> in exported headers.
>
> The headers are not added to Kbuild - so it is not exported.
> I assume thats an oversight.
>
> Sam
>
As I said it shouldn't be an exported header.
Marco
^ permalink raw reply
* Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
From: Marco @ 2009-06-14 7:15 UTC (permalink / raw)
To: Jamie Lokier; +Cc: Linux Embedded, Linux Kernel, Linux FS Devel, Daniel Walker
In-Reply-To: <20090613155957.GA16220@shareable.org>
Jamie Lokier wrote:
> Marco wrote:
>> Linux traditionally had no support for a persistent, non-volatile
>> RAM-based filesystem, persistent meaning the filesystem survives a
>> system reboot or power cycle intact. The RAM-based filesystems such as
>> tmpfs and ramfs have no actual backing store but exist entirely in the
>> page and buffer caches, hence the filesystem disappears after a system
>> reboot or power cycle.
>
> Why is a ramdisk not sufficient for this?
>
Simply because the ramdisk was not designed to work in a persistent
environment. In addition this kind of filesystem has been designed to
work not only with classic ram. You can think at the situation where you
have got an external SRAM with a battery for example. With it you can
"remap" in an easy way the SRAM. Moreover there's the issue of memory
protection that this filesystem takes care.
> Why is an entire filesystem needed, instead of simply a block driver
> if the ramdisk driver cannot be used?
>
From documentation:
"A relatively straight-forward solution is to write a simple block
driver for the non-volatile RAM, and mount over it any disk-based
filesystem such as ext2/ext3, reiserfs, etc.
But the disk-based fs over non-volatile RAM block driver approach has
some drawbacks:
1. Disk-based filesystems such as ext2/ext3 were designed for optimum
performance on spinning disk media, so they implement features such
as block groups, which attempts to group inode data into a contiguous
set of data blocks to minimize disk seeking when accessing files. For
RAM there is no such concern; a file's data blocks can be scattered
throughout the media with no access speed penalty at all. So block
groups in a filesystem mounted over RAM just adds unnecessary
complexity. A better approach is to use a filesystem specifically
tailored to RAM media which does away with these disk-based features.
This increases the efficient use of space on the media, i.e. more
space is dedicated to actual file data storage and less to meta-data
needed to maintain that file data.
2. If the backing-store RAM is comparable in access speed to system memory,
there's really no point in caching the file I/O data in the page
cache. Better to move file data directly between the user buffers
and the backing store RAM, i.e. use direct I/O. This prevents the
unnecessary populating of the page cache with dirty pages. However
direct I/O has to be enabled at every file open. To enable direct
I/O at all times for all regular files requires either that
applications be modified to include the O_DIRECT flag on all file
opens, or that a new filesystem be used that always performs direct
I/O by default."
On this point I'd like to hear other embedded guys.
> It just struck me as a lot of code which might be completely
> unnecessary for the desired functionality.
>
> -- Jamie
>
^ permalink raw reply
* Re: Representing Embedded Architectures at the Kernel Summit
From: Grant Likely @ 2009-06-14 3:48 UTC (permalink / raw)
To: Kumar Gala
Cc: Jean-Christophe PLAGNIOL-VILLARD, Josh Boyer, James Bottomley,
ksummit-2009-discuss, linux-arch, linux-embedded
In-Reply-To: <1B5FD82F-79A5-4FD1-BA99-59F3041B0470@kernel.crashing.org>
On Wed, Jun 10, 2009 at 5:13 PM, Kumar Gala<galak@kernel.crashing.org> wrote:
>
> On Jun 2, 2009, at 5:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
>> I'd like to propose AMP and kernel relocate
>> as more and SoC will came with multiple core with or without the same arch
>
> I think AMP or at least the idea of the kernel communicating with other OSes
> on the same SoC in multi-core systems is interesting.
Indeed, and not just for SoCs. I'm currently looking at Ira's
adaptation of virtio to use it for IPC between two separate CPUs
running separate Linux instances and connected via PCI.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 04/14] Pramfs: Mounting as root filesystem
From: Arnd Bergmann @ 2009-06-13 23:04 UTC (permalink / raw)
To: Marco; +Cc: Linux FS Devel, Linux Embedded, Linux Kernel, Daniel Walker
In-Reply-To: <4A33A7D7.3040008@gmail.com>
On Saturday 13 June 2009, Marco wrote:
> void __init mount_root(void)
> {
> +#ifdef CONFIG_ROOT_PRAMFS
> + if (MAJOR(ROOT_DEV) == MEM_MAJOR) {
> + if (mount_pramfs_root())
> + return;
> +
> + printk(KERN_ERR "VFS: Unable to mount root fs via PRAMFS, trying floppy.\n");
> + ROOT_DEV = Root_FD0;
> + }
> +#endif
AFAICT, this will prevent booting from /dev/ram0 with a regular file system,
because that also uses MAJOR(ROOT_DEV) == 1.
Arnd <><
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox