Re: [PATCH 01/17] pramfs: documentation
Il 10/01/2011 18:35, Luck, Tony ha scritto: >> You'd be better running ext2 over special block device, >> it is quite simple. > > Marco, > > You might want to spend some more time answering this question > (it is a particularly good one). What are the reasons to use > pramfs, rather than a ext2 over a mem<->block driver. You covered > some in your part 0 patch (like ext2 wastes time getting optimal > block placement for rotating media). But it might be a good idea > to go back over them here. From my (lightweight) reading of your > code, it looks like the biggest benefit is avoiding duplicating > the data in the pramfs memory region and the VM page cache ... > which is a big deal for your target audience of hand held devices > where memory is a somewhat scarce resource. But you probably > have other goodness in there too. > > -Tony > I can add that you can "place" the fs wherever you want, ext2 not without to build something "special" as Pavel said. Sincerely I don't know what other add. I think documentation, web site information and benchmark say all. You have got a fs that it's simple, it doesn't consume a lot of resources (you can do a fine tuning via N and bpi options for the metadata space for example), better in performance in this "environment", with the memory protection feature when availableother? I could write a piece of code that it turn on your coffee machine at morning, what do you think? :) Marco -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/17] pramfs: documentation
> You'd be better running ext2 over special block device, > it is quite simple. Marco, You might want to spend some more time answering this question (it is a particularly good one). What are the reasons to use pramfs, rather than a ext2 over a mem<->block driver. You covered some in your part 0 patch (like ext2 wastes time getting optimal block placement for rotating media). But it might be a good idea to go back over them here. From my (lightweight) reading of your code, it looks like the biggest benefit is avoiding duplicating the data in the pramfs memory region and the VM page cache ... which is a big deal for your target audience of hand held devices where memory is a somewhat scarce resource. But you probably have other goodness in there too. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Move an assert under DEBUG_KERNEL. (attempt 2)
On Mon, 10 Jan 2011 02:35:33 -0600 Rob Landley wrote:
> On 01/06/2011 05:41 PM, Andrew Morton wrote:
> > Probably a worthwhile thing to do, IMO. If there's some net-specific
> > CONFIG_DEBUG_ setting then that wold be a better thing to use.
> >
> > However the patch was a) wordwrapped, b) space-stuffed and c) not cc'ed
> > to the networking list. So its prospects are dim.
>
> Ok, either I've beaten thunderbird into submission, or I'll be submitting a
> patch to Documentation/email-clients.txt. (Whether or not I need to find a
> different smtp server to send this through remains an open question.)
>
> (Confirming: I looked for a more specific DEBUG symbol, but couldn't find
> one. I can add one, but this seems a bit small to have its own symbol, and
> DEBUG_KERNEL is already used in a few *.c files.)
>
> From: Rob Landley
>
> Move an assert under DEBUG_KERNEL. (Minor cleanup to save a few bytes.)
>
> Signed-off-by: Rob Landley
> ---
>
> include/linux/rtnetlink.h |4
> 1 file changed, 4 insertions(+)
Hm, cc to linux-net should be to netdev instead (so I changed it).
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index bbad657..28c4025 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -782,6 +782,7 @@ extern struct netdev_queue
> *dev_ingress_queue_create(struct net_device *dev);
> extern void rtnetlink_init(void);
> extern void __rtnl_unlock(void);
>
> +#ifdef CONFIG_DEBUG_KERNEL
> #define ASSERT_RTNL() do { \
> if (unlikely(!rtnl_is_locked())) { \
> printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \
> @@ -789,6 +790,9 @@ extern void __rtnl_unlock(void);
> dump_stack(); \
> } \
> } while(0)
> +#else
> +#define ASSERT_RTNL()
> +#endif
Empty macros in Linux usually take the (preferred) form of this one from
kernel.h:
#define might_resched() do { } while (0)
although it's up to DaveM in this case.
>
> static inline u32 rtm_get_table(struct rtattr **rta, u8 table)
> {
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Move an assert under DEBUG_KERNEL. (attempt 2)
On Mon, 10 Jan 2011 02:35:33 -0600 Rob Landley wrote:
> On 01/06/2011 05:41 PM, Andrew Morton wrote:
> > Probably a worthwhile thing to do, IMO. If there's some net-specific
> > CONFIG_DEBUG_ setting then that wold be a better thing to use.
> >
> > However the patch was a) wordwrapped, b) space-stuffed and c) not cc'ed
> > to the networking list. So its prospects are dim.
>
> Ok, either I've beaten thunderbird into submission, or I'll be submitting a
> patch to Documentation/email-clients.txt. (Whether or not I need to find a
> different smtp server to send this through remains an open question.)
Hi Rob,
The patch applies cleanly. However, if you have any additions/updates to
Documentation/email-clients.txt, please send them along.
and please do hard CR/LF every 70-72 characters or so, instead of
very_long_lines.
> (Confirming: I looked for a more specific DEBUG symbol, but couldn't find
> one. I can add one, but this seems a bit small to have its own symbol, and
> DEBUG_KERNEL is already used in a few *.c files.)
>
> From: Rob Landley
>
> Move an assert under DEBUG_KERNEL. (Minor cleanup to save a few bytes.)
>
> Signed-off-by: Rob Landley
> ---
>
> include/linux/rtnetlink.h |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index bbad657..28c4025 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -782,6 +782,7 @@ extern struct netdev_queue
> *dev_ingress_queue_create(struct net_device *dev);
> extern void rtnetlink_init(void);
> extern void __rtnl_unlock(void);
>
> +#ifdef CONFIG_DEBUG_KERNEL
> #define ASSERT_RTNL() do { \
> if (unlikely(!rtnl_is_locked())) { \
> printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \
> @@ -789,6 +790,9 @@ extern void __rtnl_unlock(void);
> dump_stack(); \
> } \
> } while(0)
> +#else
> +#define ASSERT_RTNL()
> +#endif
>
> static inline u32 rtm_get_table(struct rtattr **rta, u8 table)
> {
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Move an assert under DEBUG_KERNEL. (attempt 2)
On 01/06/2011 05:41 PM, Andrew Morton wrote:
> Probably a worthwhile thing to do, IMO. If there's some net-specific
> CONFIG_DEBUG_ setting then that wold be a better thing to use.
>
> However the patch was a) wordwrapped, b) space-stuffed and c) not cc'ed
> to the networking list. So its prospects are dim.
Ok, either I've beaten thunderbird into submission, or I'll be submitting a
patch to Documentation/email-clients.txt. (Whether or not I need to find a
different smtp server to send this through remains an open question.)
(Confirming: I looked for a more specific DEBUG symbol, but couldn't find one.
I can add one, but this seems a bit small to have its own symbol, and
DEBUG_KERNEL is already used in a few *.c files.)
From: Rob Landley
Move an assert under DEBUG_KERNEL. (Minor cleanup to save a few bytes.)
Signed-off-by: Rob Landley
---
include/linux/rtnetlink.h |4
1 file changed, 4 insertions(+)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index bbad657..28c4025 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -782,6 +782,7 @@ extern struct netdev_queue *dev_ingress_queue_create(struct
net_device *dev);
extern void rtnetlink_init(void);
extern void __rtnl_unlock(void);
+#ifdef CONFIG_DEBUG_KERNEL
#define ASSERT_RTNL() do { \
if (unlikely(!rtnl_is_locked())) { \
printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \
@@ -789,6 +790,9 @@ extern void __rtnl_unlock(void);
dump_stack(); \
} \
} while(0)
+#else
+#define ASSERT_RTNL()
+#endif
static inline u32 rtm_get_table(struct rtattr **rta, u8 table)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/17] pramfs: documentation
2011/1/10 Pavel Machek : >> On 07/01/2011 22:59, Tony Luck wrote: >> > On Fri, Jan 7, 2011 at 12:30 PM, Marco Stornelli >> > wrote: >> >> constraint). About the errors: pramfs does not maintain file data in the >> >> page caches for normal file I/O, so no writeback, the read/write >> >> operation are done with direct io and they are always sync. The data are >> >> write protected in hw when the arch provide this facility (x86 does). >> >> Inode contains a checksum and when there are problems they are marked as >> >> bad. Superblock contains checksum and there is a redundant superblock. >> > >> > But you can still get pramfs inconsistencies if the system crashes at an >> > inopportune moment. E.g. when making files you write the new inode to >> > pramfs, and then you insert the entry into the directory. A crash between >> > these two operations leaves an allocated inode that doesn't appear in >> > any directory. Without a fsck option, it will be hard to see that you have >> > this problem, and your only recovery option is to wipe *all* files by >> > making >> > a new filesystem. >> >> Is it a problem if you lost some logs? However do you expect that fsck >> in this case will drop the inode? > > Ask it the other way around. > > What is persistent filesystem good for when it is only persistent > sometimes? > > You'd be better running ext2 over special block device, it is quite simple. > Ok I can work on it. However can an userspace tool prevent the insert of fs in linux next? Marco -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/17] pramfs: documentation
> On 07/01/2011 22:59, Tony Luck wrote: > > On Fri, Jan 7, 2011 at 12:30 PM, Marco Stornelli > > wrote: > >> constraint). About the errors: pramfs does not maintain file data in the > >> page caches for normal file I/O, so no writeback, the read/write > >> operation are done with direct io and they are always sync. The data are > >> write protected in hw when the arch provide this facility (x86 does). > >> Inode contains a checksum and when there are problems they are marked as > >> bad. Superblock contains checksum and there is a redundant superblock. > > > > But you can still get pramfs inconsistencies if the system crashes at an > > inopportune moment. E.g. when making files you write the new inode to > > pramfs, and then you insert the entry into the directory. A crash between > > these two operations leaves an allocated inode that doesn't appear in > > any directory. Without a fsck option, it will be hard to see that you have > > this problem, and your only recovery option is to wipe *all* files by making > > a new filesystem. > > Is it a problem if you lost some logs? However do you expect that fsck > in this case will drop the inode? Ask it the other way around. What is persistent filesystem good for when it is only persistent sometimes? You'd be better running ext2 over special block device, it is quite simple. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
