On Thu, 6 Dec 2007, Andi Drebes wrote:
This requires changing the on-disk-structure (even the current little endian
only one).
That makes no sense.
Your whole patch is about making it little-endian only.
If you do that, then big-endian is screwed. I'm ok with that, and support
it.
But
On Thu, 6 Dec 2007, Jörn Engel wrote:
How about shifting and masking _before_ converting to host endianness?
static inline u32 cramfs_offset(struct cramfs_inode *inode)
{
return le32_to_cpu(node-namelen_offset
CRAMFS_NAMELEN_WIDTH);
}
Stop this
On Tue, 4 Dec 2007, Andi Drebes wrote:
Sure. This saves some definitions (and lines of code)...
Here's the new patch (tested on the same machines mentioned in the first
message).
I tried to move as many lines as possible out of the endian dependent section.
This really is the totally
On Tue, 4 Dec 2007, Andi Drebes wrote:
Perhaps I'm missing somehting, but I think for cramfs, unfortunately,
there has to be this statement. The bitfields in the cramfs_inode structure
cause some problems.
I agree that bitfields can be painful, but they should likely be just
rewritten to
On Fri, 16 Nov 2007, Andi Drebes wrote:
I'll write a new patch for inclusion in the mainline kernel that makes
cramfs little endian only. For people who really want to be able to
mount filesystems with both kinds of endianness there will be a seperate
patch (not intended to be merged
On Thu, 15 Nov 2007, Andi Drebes wrote:
This patch introduces the mount option swapendian for cramfs.
When this option is set, cramfs is able to mount an image that
was created on a machine whose endianness differs from the mounting
machine's one.
Please don't do it this way.
It would be
On Thu, 15 Nov 2007, Linus Torvalds wrote:
It would be *much* better to just standardize on one endianness, and be
done with it. That way there are no config options, no confusion, and the
code is smaller, simpler, and faster.
.. it's also statically checkable with tools like sparse, so
On Thu, 15 Nov 2007, Christoph Hellwig wrote:
Actually there are as lots of initrd are cramfs. This means you'd need
to update mkcramfs all big endian machines out there.
So? Normally the initrd goes with the kernel anyway.
Linus
-
To unsubscribe from this list: send the
On Mon, 1 Oct 2007, Zach Brown wrote:
If you're soliciting opinions, I think I tend to prefer the feel of the
code paths after the changes. I don't know the benefits of the change
are worth the risk in unmaintained file systems, though.
+ return ERR_PTR(PTR_ERR(inode));
On Mon, 1 Oct 2007, Christoph Hellwig wrote:
befs_lookup, which the above gem is from, returns a dentry *.
Ahh, ok. Then it actually makes sense. Although I'd prefer it if people
planned on writing code like that more along the lines of
error = PTR_ERR(inode);
if
On Tue, 18 Sep 2007, Nick Piggin wrote:
ROFL! Yeah of course, how could I have forgotten about our trusty OOM killer
as the solution to the fragmentation problem? It would only have been funnier
if you had said to reboot every so often when memory gets fragmented :)
Can we please stop this
On Tue, 18 Sep 2007, Andrea Arcangeli wrote:
Many? I can't recall anything besides PF_MEMALLOC and the decision
that the VM is oom.
*All* of the buddy bitmaps, *all* of the GPF_ATOMIC, *all* of the zone
watermarks, everything that we depend on every single day, is in the end
just about
On Wed, 19 Sep 2007, Nathan Scott wrote:
FWIW (and I hate to let reality get in the way of a good conspiracy) -
all SGI systems have always defaulted to using 4K blocksize filesystems;
Yes. And I've been told that:
there's very few customers who would use larger
.. who apparently would
On Wed, 19 Sep 2007, Rene Herman wrote:
Well, not so sure about that. What if one of your expected uses for example is
video data storage -- lots of data, especially for multiple streams, and needs
still relatively fast machinery. Why would you care for the overhead af
_small_ blocks?
..
On Wed, 19 Sep 2007, Rene Herman wrote:
I do feel larger blocksizes continue to make sense in general though. Packet
writing on CD/DVD is a problem already today since the hardware needs 32K or
64K blocks and I'd expect to see more of these and similiar situations when
flash gets (even)
On Sun, 16 Sep 2007, Jörn Engel wrote:
I have been toying with the idea of having seperate caches for pinned
and movable dentries. Downside of such a patch would be the number of
memcpy() operations when moving dentries from one cache to the other.
Totally inappropriate.
I bet 99% of all
On Sun, 16 Sep 2007, Jörn Engel wrote:
My approach is to have one for mount points and ramfs/tmpfs/sysfs/etc.
which are pinned for their entire lifetime and another for regular
files/inodes. One could take a three-way approach and have
always-pinned, often-pinned and rarely-pinned.
We
On Mon, 27 Aug 2007, Al Viro wrote:
I have the beginning of that series done and the rest mapped out in enough
details to implement it over this week. If somebody has objections,
questions or comments - yell.
From your description, I have no objections - everything sounds good. My
only
On Wed, 15 Aug 2007, David Howells wrote:
Would you object greatly to functions like vfs_mkdir() gaining a security
parameter? What I'm thinking of is this:
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
struct security *security)
I
On Wed, 14 Feb 2007, Andreas Gruenbacher wrote:
Mountpoints are reported relative to the chroot if they are reachable from
the
chroot, and relative to the namespace they are defined in otherwise. This is
big nonsense, but it's unclear to me how to best fix it:
Well, it's also what a
On Tue, 30 Jan 2007, Bodo Eggert wrote:
change pipefs to use a unique inode number equal to the memory
address unless it would be truncated.
I *really* wouldn't want to expose kernel addresses to user space, it just
ends up being a piece of data that they shouldn't have. If we have some
On Tue, 30 Jan 2007, Jeff Layton wrote:
Also, that patch would break many 32-bit programs not compiled with large
offsets when run in compatibility mode on a 64-bit kernel. If they were to
do a stat on this inode, it would likely generate an EOVERFLOW error since
the pointer address would
On Fri, 19 Aug 2005, Anton Altaparmakov wrote:
struct page *page;
page = find_get_page(dentry-d_inode-i_mapping, 0);
if (!page)
BUG();
Something has truncated the mapping.
My guess is that you had a cache invalidate event
On Fri, 19 Aug 2005, Linus Torvalds wrote:
The generic page cache for symlinks code does _not_ support invalidating
the cache while it's being used. A local filesystem will obviously never
invalidate the cache at all.
Hmm.. NFS _does_ use the page cache for symlinks [..]
Looking more
On Fri, 19 Aug 2005, Linus Torvalds wrote:
- document this as a fundamental fact, and apply the ncpfs patch. Local
filesystems can still continue to use the generic helper functions
(all other users _are_ local filesystems).
Actually, looking at the ncpfs patch, I'd rather
On Fri, 19 Aug 2005, Al Viro wrote:
FWIW, I'd rather take page_symlink(), page_symlink_inode_operations,
page_put_link(), page_follow_link_light(), page_readlink(), page_getlink(),
generic_readlink() and vfs_readlink() to the same place where these guys
would live. They all belong
On Fri, 19 Aug 2005, Anton Altaparmakov wrote:
It does disable link caching. But I didn't make this up. This is exactly
what smbfs uses. I just copied smbfs given ncpfs copies almost everything
smbfs does anyway...
Can you test whether the untested test-patch I sent out seems to work
On Fri, 19 Aug 2005, Anton Altaparmakov wrote:
Yes, sure. I have applied your patch to our 2.6.11.4 tree (with the one
liner change I emailed you just now) and have kicked off a compile.
Actually, hold on. The original patch had another problem: it returned an
uninitialized page pointer
If we're going to do this for a major filesystem, then I'd really just
rather see this being done generically during 2.5.x, making u be a
pointer only, and having the generic iput() just always free the dang
thing.
Linus
-
To unsubscribe from this list: send the line
On Wed, 27 Jun 2001, Ben LaHaise wrote:
On Wed, 27 Jun 2001, Linus Torvalds wrote:
If we're going to do this for a major filesystem, then I'd really just
rather see this being done generically during 2.5.x, making u be a
pointer only, and having the generic iput() just always free
On Wed, 27 Jun 2001, Alexander Viro wrote:
We get inode initilization (generic parts) spread all over the place and
sooner or later it's going to bite us, for one thing.
I don't really think so. The struct inode has become less and less
important as far as the VFS layer is concerned, and
On Tue, 12 Jun 2001, Alexander Viro wrote:
On Tue, 12 Jun 2001, Linus Torvalds wrote:
release the page cache part of the page count, but we'll leave the buffers
untouched because somebody is still using them. It's really nothing but a
the page is still busy, we'll delay the free thing
On Tue, 12 Jun 2001, Alexander Viro wrote:
OK, let me describe the race again:
And let me descibe the BUG again.
* block_flushpage() makes highmem page anonymous.
* at some point, after the buffers are not busy, but before page_launder()
sees the page again we get invalidate_buffers()
On Tue, 12 Jun 2001, Alexander Viro wrote:
We need a bit more - set_blocksize() is another source of the same problem,
AFAICS. How about the following?
Makes sense.
The set_blocksize() thing looks like it could have bit us before - it
didn't check page-mapping, so it could make mapped
On Tue, 22 May 2001, Jan Harkes wrote:
something like,
ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen,
void *outbuf, size_t outlen);
As far as functionality and errors it works like read/write in a single
call, pretty much what Richard
On Mon, 21 May 2001, Alan Cox wrote:
Sure. But we have to do two syscalls only if ioctl has both in- and out-
arguments that way. Moreover, we are talking about non-trivial in- arguments.
How many of these are in hotspots?
There is also a second question. How do you ensure the read is
On Sun, 20 May 2001, Alexander Viro wrote:
On Sun, 20 May 2001, Matthew Wilcox wrote:
On Sun, May 20, 2001 at 03:11:53PM -0400, Alexander Viro wrote:
Pheeew... Could you spell about megabyte of stuff in ioctl.c?
No.
$ ls -l arch/*/kernel/ioctl32*.c
-rw-r--r--1 willy
On Mon, 21 May 2001, Ingo Molnar wrote:
On Sun, 20 May 2001, Alexander Viro wrote:
Linus, as much as I'd like to agree with you, you are hopeless
optimist. 90% of drivers contain code written by stupid gits.
90% of drivers contain code written by people who do driver development in
On Sun, 20 May 2001, Russell King wrote:
On Sun, May 20, 2001 at 11:46:33AM -0700, Linus Torvalds wrote:
Nobody will expect the above to work, and everybody will agree that the
above is a BUG if the read() call will actually follow the pointer.
I didn't say anything about read(). I
On Sat, 19 May 2001, Ben LaHaise wrote:
1. Generic lookup method and argument parsiing (fs/lookupargs.c)
Looks sane.
2. Restricted block device (drivers/block/blkrestrict.c)
This is not very user-friendly, but along with symlinks this makes perfect
sense. It would make partition handling
On Sat, 19 May 2001, Alexander Viro wrote:
Folks, before you get all excited about cramming side effects into
open(2), consider the following case:
Your argument is stupid, imnsho.
Side-effects are perfectly fine if they are _local_ to the file
descriptor. Your example is contrieved
41 matches
Mail list logo
