[fpc-pascal] syscalls and fpc

[ik]

OK, so why don't you just say that you do not understand ?!

Let me start again. I never said that you, Micha, Daniel, Peter,
Florian, or even the big bad wolf should implement all of the given
syscall functions in the each platform in the world.

The design of Do_SysCall at this time is hurting the usage of
syscalls, for 3 reasons:

1. There is a support only for up to 6 parameters (plus the instruction itself).
2. It support only integer base parameters, while you can not pass
pointers, chars, array, record or floating point types.
3. Each OS changes/add/remove functions frequently, so assuming one of
the above making the functions unusable for anything that is not an
integer and up to 6 parameters.

(If you do not understand my points please ask, and I'll try to clear it up)

Now one *example* (that caused me to notice this issues) is the following:

extern int inotify_add_watch (int __fd, const char *__name, uint32_t __mask)

(Inotify is a Linux *only* feature that allows you to listen to any
file system event on request, and it replacing the dnotify event, that
had many issues).

So as you can see by the Do_SysCall function(s):

function Do_SysCall(sysnr,param1,param2,param3,param4,param5,param6:TSysParam):TSysResult;
 external name 'FPC_SYSCALL6';

They unable to give you an answer to the above deceleration.
So my questions are (still):

1. Is there a way to implement the above with array of const ?
2. Is there a way to implement the above without using assembly, and
if you must use assembly, then is there a way to use array of const
inside the assembly, and if so, how ?

As you can see, I still haven't requested anyone to do it for me, I'm
only trying to figure out how to achieve the above request with
syscall using FPC !

Here is a small way to do it btw, but it will be problematic with
records (if you use assembly):

function Do_SysCall(sysnr : TSysParam; const
param1,param2,param3,param4,param5,param6) : TSysResult;  external
name 'FPC_SYSCALL6';

The problem is of course the number of bits that the registers can
store in them (32 bit in i386 and 64 bit on x86_64).
So when Micha mentioned the registers, I asked if my knowledge is
valid, that you can do the following:

push param1
push param2
push param3
...
push param6

And as you can see, you do not need to use specific register, but the
system handle the bits for you.
I hope you do understand the problematic design of Do_SysCall, and I
hope you now understand what I'm asking and talking about. If you do
not understand any point, please ask instead of arguing.


Regardless of that, I do not expect FPC to have implementation of 100%
of each system SysCall, because if I require to use a syscal, I'll
call it,. or bind it:

function Do_SysCall(sysnr : TSysParam; const
param1,param2,param3,param4,param5,param6) : TSysResult;  external;

That way, it will be binding to he running environment of Linux or any
other supported system. However I do not like this method, and
therefor I prefer the usage of syscall instead.


Ido

On Feb 16, 2008 2:31 AM, Marco van de Voort <marcov at stack.nl> wrote:
> > On Feb 16, 2008 2:00 AM, Marco van de Voort <marcov at stack.nl> wrote:
> > > > way it assumes the number of parameters and also the type of them, so
> > > > as I asked before, how I can either call the syscall command without
> > > > assembler, or how I can pass an array of const (prior to that I asked
> > > > regarding array of TSysParam) to assembly if three is no other way to
> > > > use syscall ?
> > >
> > > So we can write you up as volunteer to write up prototypes (and worse
> > > maintain them) for about 300 calls per OS per arch?
> >
> > So what you are saying is, that because there are many commands that
> > can be used by syscall, you prefer to give support only to the ones
> > that actually in use by most programs, rather then to write something
> > more general that will support everything, and will do it right ?
>
> There is no need to support all of them in the first place, and with formal
> typing and support, also maintaining the structs come into play, making a
> testsuite etc. Nothing that supports everything is easy, and nothing is ever
> exactly right once reality comes crashing in, except the helicopter view
> before actually getting your hands wet.
>
> > Sorry but I still don't understand... The problem is the
> > design/approach of the way syscall is implemented in FPC, while you
> > are saying that because there are so many OS/commands that each use it
> > differently, you just want to leave it as-is because it works for you
>
> No, because it works period.
>
> > So according to what you say, I can either mark that there is no
> > support for syscall in FPC (half work for most of the times is not
> > enough, it's just wrong desgin), or I don't understand whats going on.
>
> I still haven't the faintest clue what your problem actually is, aside from
> style issues. Sure it is not the neatest solution, but neither are syscalls
> in general.
>
> gcc solves it slightly better with heaps of macros and custom calling
> conventions, a luxury that we don't have. And different per OS-arch
> combination too. Moreover, there are multiple teams involved there (the
> respective kernel teams, glibc, kernel), and we have to do it ourselves.
>
> Moreover since more and more subsystems use functionality in libc that is
> more than a mere wrapper (unicode is getting more popular, the
> authentication and resolving systems get increasingly complicated due to
> security), and duplicating that on bare bones syscalls is both an awful lot
> of hard to get right work, and a security risk.
>
> But if you want me to get you of the "maintain calls" list, and put you onto
> the "create custom calling conventions by having directives that can assign
> each and other param to a precies reg" list, by all means, say so. I'd be
> happy to. I can write you up for the native unicode list and to fix netdb
> too if you wish.
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>



-- 
http://ik.homelinux.org/