linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2005-11-07	[JFFS2] Clean up trailing white spaces	Thomas Gleixner	1	-4/+4
	Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-11-06	[JFFS2] Use f->target instead of f->dents for symlink target	Artem B. Bityutskiy	1	-14/+12
	JFFS2 uses f->dents to store the pointer to the symlink target string (in case the inode is symlink). This is somewhat ugly to use the same field for different reasons. Introduce distinct field f->target for this purpose. Note, f->fragtree, f->dents, f->target may probably be put in a union. Signed-off-by: Artem B. Bityutskiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-08-19	[PATCH] Fix up symlink function pointers	Al Viro	1	-3/+3
	This fixes up the symlink functions for the calling convention change: * afs, autofs4, befs, devfs, freevxfs, jffs2, jfs, ncpfs, procfs, smbfs, sysvfs, ufs, xfs - prototype change for ->follow_link() * befs, smbfs, xfs - same for ->put_link() Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-19	[PATCH] jffs2: fix symlink error handling	Al Viro	1	-4/+6
	The current calling conventions for ->follow_link() are already fairly complex. What we have is 1) you can return -error; then you must release nameidata yourself and ->put_link() will _not_ be called. 2) you can do nd_set_link(nd, ERR_PTR(-error)) and return 0 3) you can do nd_set_link(nd, path) and return 0 4) you can return 0 (after having moved nameidata yourself) jffs2 follow_link() is broken - it has an exit where it returns -EIO and leaks nameidata. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23	[JFFS2] Add symlink caching support.	Artem B. Bityuckiy	1	-12/+30
	Signed-off-by: Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+45
	Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!