XFS / IA64 system call conflict

David's last patch assigns the system call number 1215 to "getunwind". The XFS kernel patch for 2.4.5 vuses 1215-1217 for address control lists. How should this conflict be resolved? For now, I have just made XFS use 1216-1218 instead.

Martin

Martin Wilck     <[email protected]>
FSC EP PS DS1, Paderborn      Tel. +49 5251 8 15113

In the XFS CVS tree, the system calls have moved to the range 1260-1262. We are in the process of getting some official numbers.

Nate Straz                                              [email protected]
sgi, inc                                           http://www.sgi.com/
Linux Test Project                                  http://ltp.sf.net/

Martin> David's last patch assigns the system call number 1215 to Martin> "getunwind". The XFS kernel patch for 2.4.5 vuses 1215-1217 Martin> for address control lists. How should this conflict be Martin> resolved? For now, I have just made XFS use 1216-1218 instead.

Please don't do this. If you want to use temporary numbers, bump them out of range so we don't clash with them in the next kernel release. I'd say pick something like 8000 for now.

Jes

The XFS syscalls for IA64 are now
data8 sys_attrctl // 1260
data8 sys_acl_get
data8 sys_acl_set
with corresponding changes to include/asm-ia64/unistd.h.

I did some SGI internal patches for XFS+KDB against IA64 a few weeks ago. The problem is that IA64 is stuck on kernel 2.4.5 while XFS development is up to 2.4.7. There were changes to common kernel code between 2.4.5 and 2.4.7 that affected fs handling so we cannot backport the current XFS to the 2.4.5 IA64 kernel. Instead I used a snapshot of XFS as of 2.4.5, which means it is missing some bug fixes. We would really like a current IA64 kernel.

The tables only go up to 1279 so I picked an arbitrary number in the middle.

Keith> The problem is that IA64 is stuck on kernel 2.4.5 while XFS Keith> development is up to 2.4.7.

Don't worry, a 2.4.7 based patch is in the works (and, no, I won't apologize for going on vacation...).

What bothers me is that you apparently did not even try to contact me to get official numbers. At least, I don't see any earlier message from you in this regard.

	--david

Keith> The XFS syscalls for IA64 are now data8 sys_attrctl // 1260 Keith> data8 sys_acl_get data8 sys_acl_set with corresponding Keith> changes to include/asm-ia64/unistd.h.

No they are not. If you need system call numbers, send me mail and I'll assign you the necessary numbers.

	--david

There is no 'official' source for syscall numbers. The lack of a standard process for assigning new syscall numbers is one of the annoying things about the kernel and glibc. Everybody picks their own on every arch, which almost guarantees conflicts.

Keith> There is no 'official' source for syscall numbers.

Yes, there is: you send me mail, I add the respective numbers to unistd.h, and that's it. Anyone who messes with that protocol is on his/her own.

	--david

PS: Note that syscall numbers are arch specific, so if you're looking
for a platform-independent process, you're looking for the wrong thing.

Do you take care of glibc as well? That is where the problem tends to occur.

In any case the XFS syscalls are for the SGI version of ACLs. There are other projects working on ACLs, until there is agreement about the ACL syscall interface, the XFS numbers cannot be considered to be permanent. So yes, we are on our own for the moment.

Keith> Do you take care of glibc as well? That is where the problem Keith> tends to occur.

glibc is a *user* of the kernel's system call numbers, so I don't see how this could create a problem. Perhaps you're worried about the name of the libc system call?

Keith> In any case the XFS syscalls are for the SGI version of ACLs. Keith> There are other projects working on ACLs, until there is Keith> agreement about the ACL syscall interface, the XFS numbers Keith> cannot be considered to be permanent. So yes, we are on our Keith> own for the moment.

Fine by me provided you make sure that the users of XFS understand that. It does sound though that it would be premature to recommend widespread use of XFS at this time.

	--david

On the contrary. ACLs are an add on to XFS, you can run XFS quite happily without ACLs.

Keith> On Mon, 23 Jul 2001 17:19:36 -0700, David Mosberger

Keith> Do you take care of glibc as well? That is where the problem Keith> tends to occur.

There isn't really a thing as special syscall handling in glibc in this regard. However if you want wrappers added to glibc, just mail me and I will do it (for glibc/ia64).

Jes