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 unsubscr
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 hig
> 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
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 cop
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
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 de
