Re: [PATCH] UBI: new module ubiblk: block layer on top of UBI
TODO: * the modules keeps a table of the devices which length is the maximum number of UBI volumes. It should make use of a linked list. A linked list isn't very nice either. Try using idr, which gives you both an allocator for the minor number space, and a way to look up the structure by that index. Advantages of ubiblk over gluebi+mtdblock_ro: This section should be in the main commit log, and not that part with the changelog which gets dropped. +int major; Please don't use global variables with generic names. In this case you should neither make it global nor give it a generic name. -- 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] module: Use binary search in lookup_symbol()
On Tue, May 17, 2011 at 04:33:07PM -0700, Tim Bird wrote: That said, I can answer Greg's question. This is to speed up the symbol resolution on module loading. The last numbers I saw showed a reduction of about 15-20% for the module load time, for large-ish modules. Of course this is highly dependent on the size of the modules, what they do at load time, and how many symbols are looked up to link them into the kernel. How large are these very large modules, and what are good examples for that? And why do people overly care for the load time? -- 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 15/16] pramfs: test module
On Mon, Oct 11, 2010 at 01:24:04PM +0100, Kieran Bingham wrote: @@ -0,0 +1,49 @@ +/* + * FILE NAME fs/pramfs/namei.c FILE NAME != namei.c Yes, that's why you should never do such filename comments which are not only utterly prone to be out of data, but also 100% useless. -- 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: [ltt-dev] [PATCH] nfs: add support for splice writes
On Mon, Apr 20, 2009 at 09:17:23PM +0530, Suresh Jayaraman wrote:
+static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
+ struct file *filp, loff_t *ppos,
+ size_t count, unsigned int flags)
+{
+ struct dentry *dentry = filp-f_path.dentry;
+
+ dprintk(NFS splice_write(%s/%s, %...@%lu)\n,
+ dentry-d_parent-d_name.name, dentry-d_name.name,
+ (unsigned long) count, (unsigned long long) *ppos);
+
+ return generic_file_splice_write(pipe, filp, ppos, count, flags);
+}
+
You need all calls from nfs_file_write, too:
- most importantly the nfs_revalidate_file_size for O_APPEND
- the nfs_do_fsync for sync writes
- probably the stats increment
--
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 [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: On Friday 02 of January 2009, Rob Landley wrote: Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel never required perl to be installed on the build system. (Various development and debugging scripts were written in perl and python and such, but they weren't involved in actually building a kernel.) Building a kernel before 2.6.25 could be done with a minimal system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing else. And now bash is going to be required... while some distros don't need/have bash. /bin/sh should be enough. *nod* bash is in many ways a worse requirement than perl. strict posix /bin/sh + awk + sed would be nicest, but if that's too much work perl seems reasonable. -- 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: Subject: [PATCH 01/16] Squashfs: inode operations
On Tue, Oct 21, 2008 at 12:14:26PM -0400, David P. Quigley wrote: I looked at where filesystems such as ext3 store these and it seems to be in include/linux. I'm assuming this is because usespace utilities like fsck need them. It seems wrong for userspace tools to have their own private copy since you can potentially have them out of sync with the kernel you are running and it provides more chance for you forgetting to update a structure somewhere. All modern filesystems have it in their directories, and ext3 will have that soon too. The only thing that should go into include/linux are defintions for ioctls if you have them. It is absolutely intention that the tools can get out of sync with the kernel, because that actually keeps them compiling when you update things in the kernel - note that a single on disk format can be represented by lots of different things in C, and for various reaosons those can change once in a while in the kernel. It also allows you to actually compile the tools on a system that doesn't have new enough kernel headers yet (e.g. debian autobuilders) or even run the tools on various platforms that have no or different kernel implementations. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
