On Thu, Mar 01, 2007 at 10:44:16PM +, Dave Kleikamp wrote:
> Would EINVAL (or whatever) make it back to the caller of
> posix_fallocate(), or would glibc fall back to its current
> implementation?
>
> Forgive me if I haven't put enough thought into it, but would it be
> useful to create a
On Fri, Mar 02, 2007 at 12:04:45AM +0530, Amit K. Arora wrote:
> This is to give a heads up on few patches that we will be soon coming up
> with. These patches implement a new system call sys_fallocate() and a
> new inode operation "fallocate", for persistent preallocation. The new
> system call,
Amit K. Arora wrote:
Might want more error checking in there, something like (rough cut)...
(or is some of this glibc's job?)
+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
+{
+ struct file *file;
+ struct inode *inode;
+ long ret;
> +
> + ret = -EINVAL;
On Thu, 2007-03-01 at 14:59 -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 22:44:16 +
> Dave Kleikamp <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> > > On Fri, 2 Mar 2007 00:04:45 +0530
> > > "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> >
> > >
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 00:04:45 +0530
> "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > This is to give a heads up on few patches that we will be soon coming up
> > with. These patches implement a new system call sys_fallocate() and a
> > new
On Thu, 01 Mar 2007 22:44:16 +
Dave Kleikamp <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> > On Fri, 2 Mar 2007 00:04:45 +0530
> > "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
>
> > > +asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
> >
On Fri, 02 Mar 2007 09:40:54 +1100
Nathan Scott <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> > On Fri, 2 Mar 2007 00:04:45 +0530
> > "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> >
> > > This is to give a heads up on few patches that we will be soon
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 00:04:45 +0530
> "Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> > +asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
> > +{
> > + struct file *file;
> > + struct inode *inode;
> > + long ret = -EINVAL;
> That new argument might need to come after "fd" - ARM has funny
> requirements on syscall arg padding and layout.
FYI the 32bit ppc ABI does too, from arch/powerpc/kernel/sys_ppc32.c:
/*
* long long munging:
* The 32 bit ABI passes long longs in an odd even register pair.
*/
and the first
Nathan Scott wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and
On Fri, 2 Mar 2007 00:04:45 +0530
"Amit K. Arora" <[EMAIL PROTECTED]> wrote:
> This is to give a heads up on few patches that we will be soon coming up
> with. These patches implement a new system call sys_fallocate() and a
> new inode operation "fallocate", for persistent preallocation. The new
Alan wrote:
> ENOSYS indicates quite different things and ENOTTY is also used for
> syscalls. I still think ENOTTY is correct.
>
Yes, ENOSYS tends to me "operation flat out not support" rather than
"not on this object". I think we can do better than ENOTTY though -
ENOTSUP for example (modulo
On Thu, 01 Mar 2007 14:05:36 -0800
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Alan wrote:
> > A lot of people get confused about -ENOTTY, but it is the return for
> > attempting to use an ioctl on the wrong type of object, so this appears
> > to be quite correct.
>
> This is a syscall
Alan wrote:
> A lot of people get confused about -ENOTTY, but it is the return for
> attempting to use an ioctl on the wrong type of object, so this appears
> to be quite correct.
This is a syscall though; ENOSYS is probably a better match.
J
-
To unsubscribe from this list: send the line
On Thu, 01 Mar 2007 13:14:32 -0800
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Amit K. Arora wrote:
> > + if (inode->i_op && inode->i_op->fallocate)
> > + ret = inode->i_op->fallocate(inode, offset, len);
> > + else
> > + ret = -ENOTTY;
>
> You can only allocate
Amit K. Arora wrote:
> + if (inode->i_op && inode->i_op->fallocate)
> + ret = inode->i_op->fallocate(inode, offset, len);
> + else
> + ret = -ENOTTY;
You can only allocate space on typewriters? ;)
J
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Mar 01, 2007 at 03:23:19PM -0500, Jeff Garzik wrote:
> I certainly agree that we want something like this.
>
> posix_fallocate() is the glibc interface we want to be compatible with
> (which your definition is, AFAICS).
This would be great for Samba. Windows clients do this a lot
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation "fallocate", for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkage long
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkage long sys_fallocate(int
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkage
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system call, as Andrew suggested, will look like:
asmlinkage
On Thu, Mar 01, 2007 at 03:23:19PM -0500, Jeff Garzik wrote:
I certainly agree that we want something like this.
posix_fallocate() is the glibc interface we want to be compatible with
(which your definition is, AFAICS).
This would be great for Samba. Windows clients do this a lot
Amit K. Arora wrote:
+ if (inode-i_op inode-i_op-fallocate)
+ ret = inode-i_op-fallocate(inode, offset, len);
+ else
+ ret = -ENOTTY;
You can only allocate space on typewriters? ;)
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Thu, 01 Mar 2007 13:14:32 -0800
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Amit K. Arora wrote:
+ if (inode-i_op inode-i_op-fallocate)
+ ret = inode-i_op-fallocate(inode, offset, len);
+ else
+ ret = -ENOTTY;
You can only allocate space on typewriters? ;)
Alan wrote:
A lot of people get confused about -ENOTTY, but it is the return for
attempting to use an ioctl on the wrong type of object, so this appears
to be quite correct.
This is a syscall though; ENOSYS is probably a better match.
J
-
To unsubscribe from this list: send the line
On Thu, 01 Mar 2007 14:05:36 -0800
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Alan wrote:
A lot of people get confused about -ENOTTY, but it is the return for
attempting to use an ioctl on the wrong type of object, so this appears
to be quite correct.
This is a syscall though; ENOSYS
Alan wrote:
ENOSYS indicates quite different things and ENOTTY is also used for
syscalls. I still think ENOTTY is correct.
Yes, ENOSYS tends to me operation flat out not support rather than
not on this object. I think we can do better than ENOTTY though -
ENOTSUP for example (modulo the
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system
Nathan Scott wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
That new argument might need to come after fd - ARM has funny
requirements on syscall arg padding and layout.
FYI the 32bit ppc ABI does too, from arch/powerpc/kernel/sys_ppc32.c:
/*
* long long munging:
* The 32 bit ABI passes long longs in an odd even register pair.
*/
and the first
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
+{
+ struct file *file;
+ struct inode *inode;
+ long ret = -EINVAL;
+ file =
On Fri, 02 Mar 2007 09:40:54 +1100
Nathan Scott [EMAIL PROTECTED] wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
This is to give a heads up on few patches that we will be soon coming up
with.
On Thu, 01 Mar 2007 22:44:16 +
Dave Kleikamp [EMAIL PROTECTED] wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
+{
+ struct
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode
On Thu, 2007-03-01 at 14:59 -0800, Andrew Morton wrote:
On Thu, 01 Mar 2007 22:44:16 +
Dave Kleikamp [EMAIL PROTECTED] wrote:
On Thu, 2007-03-01 at 14:25 -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 00:04:45 +0530
Amit K. Arora [EMAIL PROTECTED] wrote:
+asmlinkage long
Amit K. Arora wrote:
Might want more error checking in there, something like (rough cut)...
(or is some of this glibc's job?)
+asmlinkage long sys_fallocate(int fd, loff_t offset, loff_t len)
+{
+ struct file *file;
+ struct inode *inode;
+ long ret;
+
+ ret = -EINVAL;
+
On Fri, Mar 02, 2007 at 12:04:45AM +0530, Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system call, as
On Thu, Mar 01, 2007 at 10:44:16PM +, Dave Kleikamp wrote:
Would EINVAL (or whatever) make it back to the caller of
posix_fallocate(), or would glibc fall back to its current
implementation?
Forgive me if I haven't put enough thought into it, but would it be
useful to create a
On Thu, Mar 01, 2007 at 05:29:15PM -0600, Eric Sandeen wrote:
Amit K. Arora wrote:
Might want more error checking in there, something like (rough cut)...
(or is some of this glibc's job?)
Yeah, we need to have this checks. We can't rely on userspace not
passing arguments that might corrupt
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system call, as Andrew suggested, will look like:
On Thu, 01 Mar 2007 22:03:55 -0800 Badari Pulavarty [EMAIL PROTECTED] wrote:
Just curious .. What does posix_fallocate() return ?
bookmark this:
http://www.opengroup.org/onlinepubs/009695399/nfindex.html
Upon successful completion, posix_fallocate() shall return zero;
otherwise, an
Andrew Morton wrote:
Perhaps Ulrich can comment.
I was out of town, hence the delay.
I think that if there is no support for the syscall the correct answer
is to return ENOSYS. In this case the current userlevel code would be
used and ENOSYS is also used to trigger the use of the compat code
101 - 144 of 144 matches
Mail list logo