* syscals @ 2002-04-09 2:10 mark manning 2002-04-09 10:06 ` syscals Frank Schaefer 0 siblings, 1 reply; 6+ messages in thread From: mark manning @ 2002-04-09 2:10 UTC (permalink / raw) To: linux-kernel ok - according to unistd.h we now have exactly 256 syscalls allocated (unless im missing something). my code needs to be able to account for every single possible syscall and so i need to be able to store the syscall number in a standard way. not all syscalls are catered for on the outset by at any time the user can say "i need to use syscall x which takes y parameters" and the code will be able to take care of it. the problem is that i am currently reserving only 8 bits for the syscall number. this is ok for now but if we ever get another syscall its going to be unuseable by my existing code :) - should i be reserving 16 bits now in preperation for some new syscalls being added ? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: syscals 2002-04-09 2:10 syscals mark manning @ 2002-04-09 10:06 ` Frank Schaefer 2002-04-09 10:19 ` Compaq Alpha DS10 - Kernel 2.4.18 Oliver Pitzeier 2002-04-09 15:09 ` syscals Randy.Dunlap 0 siblings, 2 replies; 6+ messages in thread From: Frank Schaefer @ 2002-04-09 10:06 UTC (permalink / raw) To: linux-kernel On Tue, 2002-04-09 at 04:10, mark manning wrote: > ok - according to unistd.h we now have exactly 256 syscalls allocated (unless im missing something). my code needs to be able to account for every single possible syscall and so i need to be able to store the syscall number in a standard way. not all syscalls are catered for on the outset by at any time the user can say "i need to use syscall x which takes y parameters" and the code will be able to take care of it. > > the problem is that i am currently reserving only 8 bits for the syscall number. this is ok for now but if we ever get another syscall its going to be unuseable by my existing code :) - should i be reserving 16 bits now in preperation for some new syscalls being added ? > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Hmm... dunno if you got this right. There are maximal 256 syscalls possible, and, right -- exactly this amount of syscalls is in the entrytable. But alotalotalot of them are defined as sys_ni_syscall (not yet implemented). I think there is still some space for enhancements. See arch/i386/kernel/entry.S. Regards Frank ^ permalink raw reply [flat|nested] 6+ messages in thread
* Compaq Alpha DS10 - Kernel 2.4.18 2002-04-09 10:06 ` syscals Frank Schaefer @ 2002-04-09 10:19 ` Oliver Pitzeier 2002-04-09 11:25 ` Damian Wrobel 2002-04-09 12:16 ` dr john halewood 2002-04-09 15:09 ` syscals Randy.Dunlap 1 sibling, 2 replies; 6+ messages in thread From: Oliver Pitzeier @ 2002-04-09 10:19 UTC (permalink / raw) To: linux-kernel Hi all! I've got a really big problem with kernel 2.4.18 and 2.4.17 on an Alpha. I can compile, install and boot the kernel on my Alpha. But if I shutdown the machine without shutting down the system - I know this is crazy, but sometimes this happens... So if I'm this mad and restart the machine afterwards, I get a lot of fsck errors 'til the system give up and tell's me, that I have to check it with fsck myself. OK, I did so... fsck -y /dev/sda1 -> Works perfectly. After fsck has corrected more than 1000 errors I'm able to reboot the machine. And than: MY SYSTEM IS NO LONGER BOOTABLE. It's totally currupted... I never saw the filesystem curruption bug on Intel, but it sounds like this. Is this the same bug that was on Intel? Have I done something wrong? Are there any alpha-users in this list? :o)))) Greetz, I look forward for answers, Oliver ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Compaq Alpha DS10 - Kernel 2.4.18 2002-04-09 10:19 ` Compaq Alpha DS10 - Kernel 2.4.18 Oliver Pitzeier @ 2002-04-09 11:25 ` Damian Wrobel 2002-04-09 12:16 ` dr john halewood 1 sibling, 0 replies; 6+ messages in thread From: Damian Wrobel @ 2002-04-09 11:25 UTC (permalink / raw) To: linux-kernel >-----Original Message----- >From: linux-kernel-owner@vger.kernel.org >[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Oliver Pitzeier >Sent: Tuesday, April 09, 2002 12:20 PM >To: linux-kernel@vger.kernel.org >Subject: Compaq Alpha DS10 - Kernel 2.4.18 > > >Hi all! > >I've got a really big problem with kernel 2.4.18 and 2.4.17 on >an Alpha. > >I can compile, install and boot the kernel on my Alpha. >But if I shutdown the machine without shutting down the >system - I know this is crazy, but sometimes this happens... > >So if I'm this mad and restart the machine afterwards, I get >a lot of fsck errors 'til the system give up and tell's me, >that I have to check it with fsck myself. > >OK, I did so... fsck -y /dev/sda1 -> Works perfectly. After >fsck has corrected more than 1000 errors I'm able to >reboot the machine. > >And than: MY SYSTEM IS NO LONGER BOOTABLE. It's totally >currupted... > >I never saw the filesystem curruption bug on Intel, but it >sounds like this. > >Is this the same bug that was on Intel? >Have I done something wrong? > >Are there any alpha-users in this list? :o)))) > >Greetz, I look forward for answers, > Oliver > > >- Think about one of journaling filesystems: ext3, reiserfs, xfs, jfs... Regards, Damian Wrobel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Compaq Alpha DS10 - Kernel 2.4.18 2002-04-09 10:19 ` Compaq Alpha DS10 - Kernel 2.4.18 Oliver Pitzeier 2002-04-09 11:25 ` Damian Wrobel @ 2002-04-09 12:16 ` dr john halewood 1 sibling, 0 replies; 6+ messages in thread From: dr john halewood @ 2002-04-09 12:16 UTC (permalink / raw) To: linux-kernel On Tuesday 09 April 2002 11:19 am, Oliver Pitzeier wrote: > Hi all! > [...] > OK, I did so... fsck -y /dev/sda1 -> Works perfectly. After > fsck has corrected more than 1000 errors I'm able to > reboot the machine. > > And than: MY SYSTEM IS NO LONGER BOOTABLE. It's totally > currupted... > Are there any alpha-users in this list? :o)))) $uname -a Linux frumious.unidec.co.uk 2.4.19pre1 #2 Wed Feb 27 14:45:16 GMT 2002 alpha unknown Yup. Not had any problems despite a series of recent powercuts (including one where the mains voltage dropped from ~230V to ~150V), but did have very long fsck()s afterwards. So I gave up and went to ext3 - all it takes is kernel support and a quick tune2fs -j /dev/XXX ;-) cheers john ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: syscals 2002-04-09 10:06 ` syscals Frank Schaefer 2002-04-09 10:19 ` Compaq Alpha DS10 - Kernel 2.4.18 Oliver Pitzeier @ 2002-04-09 15:09 ` Randy.Dunlap 1 sibling, 0 replies; 6+ messages in thread From: Randy.Dunlap @ 2002-04-09 15:09 UTC (permalink / raw) To: Frank Schaefer; +Cc: linux-kernel On 9 Apr 2002, Frank Schaefer wrote: | On Tue, 2002-04-09 at 04:10, mark manning wrote: | > ok - according to unistd.h we now have exactly 256 syscalls allocated (unless im missing something). my code needs to be able to account for every single possible syscall and so i need to be able to store the syscall number in a standard way. not all syscalls are catered for on the outset by at any time the user can say "i need to use syscall x which takes y parameters" and the code will be able to take care of it. | > | > the problem is that i am currently reserving only 8 bits for the syscall number. this is ok for now but if we ever get another syscall its going to be unuseable by my existing code :) - should i be reserving 16 bits now in preperation for some new syscalls being added ? | > - | > | Hmm... | | dunno if you got this right. There are maximal 256 syscalls possible, | and, right -- exactly this amount of syscalls is in the entrytable. But | alotalotalot of them are defined as sys_ni_syscall (not yet | implemented). | I think there is still some space for enhancements. See | arch/i386/kernel/entry.S. Where is the limitation of 256 syscalls possible? -- ~Randy ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-04-09 15:12 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-04-09 2:10 syscals mark manning 2002-04-09 10:06 ` syscals Frank Schaefer 2002-04-09 10:19 ` Compaq Alpha DS10 - Kernel 2.4.18 Oliver Pitzeier 2002-04-09 11:25 ` Damian Wrobel 2002-04-09 12:16 ` dr john halewood 2002-04-09 15:09 ` syscals Randy.Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox