Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

C and PASCAL (or any other high-level languages) in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
ThorstenOtto
Atari God
Atari God
Posts: 1477
Joined: Sun Aug 03, 2014 5:54 pm

Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by ThorstenOtto »

Hi,

could someone confirm that there is a incompatibility between those calls? (that function is typically used for example to put a device in non-blocking mode)

The prototype (from the Kernels point of view) in both cases is:

Code: Select all

long Fcntl(short fd, long arg, short cmd)
Handling in Mint:
  • for F_GETFL, the arg parameter is ignored, and the flags are returned as result code of the function
  • for F_SETFL, the arg parameter is interpreted as the new flags to be set
Handling in MagiC seems to be:
  • for F_GETFL, the arg parameter is interpreted as a pointer to a long variable, where the flags are written
  • similarly, for F_SETFL, the arg parameter is interpreted as the *address* of a long which contains the flags to be set
In MagiC i cannot completely follow the path through the kernel, since both commands are only handled by device-drivers, but not by the dos kernel. Could someone check and/or confirm that?
ThorstenOtto
Atari God
Atari God
Posts: 1477
Joined: Sun Aug 03, 2014 5:54 pm

Re: Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by ThorstenOtto »

Bump ;) Nobody able to check this?
ThorstenOtto
Atari God
Atari God
Posts: 1477
Joined: Sun Aug 03, 2014 5:54 pm

Re: Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by ThorstenOtto »

I think i can now answer that question myself, at least for the sockets.dev driver:

Code: Select all


static long cdecl socket_ioctl(MX_DOSFD *f, short cmd, void *buf)
{
	long r;
	struct socket *so;
	
	if (cmd == SOCKETCALL)
		return socketcall(f, buf);
	switch (cmd)
	{
	case F_GETFL:
		r = f->fd_mode & 0xfff;
		if (buf)
			*((long *)buf) = r;
		return r;
	case F_SETFL:
		f->fd_mode = (short)(*((long *)buf));
		return 0;
SO for F_GETFL, MagiC behaves slightly different than MiNT, and returns the value both at the supplied pointer, and as function result.
But for F_SETFL, they are incompatible (mint uses the extra argument as value, MagiC interprets it as a pointer to a long with the value).

Its also strange that the builtin drivers don't seem to handle it at all.
neanderthal
Captain Atari
Captain Atari
Posts: 235
Joined: Sun Jul 10, 2016 10:58 pm

Re: Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by neanderthal »

ThorstenOtto wrote: Thu Jun 10, 2021 12:03 pm

Its also strange that the builtin drivers don't seem to handle it at all.
Would that be drivers as in .XIF drivers for the net-interfaces?
For do remember that tweaked in ioctl so could change setup(change physical port used) on my 3Com board,not sure how it is called or registered tho since did not need to care about it.
Cannot remember if the other drivers then had ioctl compiled in or if used some example?
Think will have a go at the old sources if brain allows later :)
ThorstenOtto
Atari God
Atari God
Posts: 1477
Joined: Sun Aug 03, 2014 5:54 pm

Re: Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by ThorstenOtto »

neanderthal wrote: Thu Jun 10, 2021 3:06 pm Would that be drivers as in .XIF drivers for the net-interfaces?
No, i don't think so. That ioctl is handled by sockets.dev, not by the drivers. Will have to check though if other ioctl constants are affected, too.
neanderthal
Captain Atari
Captain Atari
Posts: 235
Joined: Sun Jul 10, 2016 10:58 pm

Re: Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by neanderthal »

ThorstenOtto wrote: Thu Jun 10, 2021 3:18 pm
neanderthal wrote: Thu Jun 10, 2021 3:06 pm Would that be drivers as in .XIF drivers for the net-interfaces?
No, i don't think so. That ioctl is handled by sockets.dev, not by the drivers. Will have to check though if other ioctl constants are affected, too.
Oh wait,we are talking sockets.dev not the .xdd for old mint that I use,thats for MagiC right?
Anywho,as far as I can quess,a sys call would go via kernel to socket.xdd and then out to device driver in old mint for setting parameters to hardware.
At least the call in my old driver is namned el3_ioctl() and is probably registered when doing driver_init().
Have to check how the ifconfig looks or was it ifstats that had to be manually changed to get/send driver stuff?
Of course if ioctl is for setting sockets/net stuff it would not be passed to device driver,it doesn't care that much what goes in the packets :) ,well almost,some checks/fixes are done with packet.
ThorstenOtto
Atari God
Atari God
Posts: 1477
Joined: Sun Aug 03, 2014 5:54 pm

Re: Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by ThorstenOtto »

neanderthal wrote: Thu Jun 10, 2021 5:48 pm [Oh wait,we are talking sockets.dev not the .xdd for old mint that I use,thats for MagiC right?
Yes, or more precisely, about that peculiar difference between sockets.dev and sockets.xdd.
Anywho,as far as I can quess,a sys call would go via kernel to socket.xdd and then out to device driver in old mint for setting parameters to hardware.
That depends. Some are handled by the kernel, some by the socket driver, and some others are passed to the driver. The general interface is the same in all cases, but the interpretation of the extra argument depends on the type of call.
neanderthal
Captain Atari
Captain Atari
Posts: 235
Joined: Sun Jul 10, 2016 10:58 pm

Re: Incompatibility betweeen MagiC/MiNT for Fcntl(F_GETFL/F_SETFL)

Post by neanderthal »

ThorstenOtto wrote: Thu Jun 10, 2021 5:56 pm
neanderthal wrote: Thu Jun 10, 2021 5:48 pm [Oh wait,we are talking sockets.dev not the .xdd for old mint that I use,thats for MagiC right?
Yes, or more precisely, about that peculiar difference between sockets.dev and sockets.xdd.
Yes have been sort of checking up on your progress since had some strangeness when tested a more update kernel once and my driver did not load.
Did not do much testing since quess have to recompile the whole thing for the new ones,quessing that the built in style changed registering or something
Anywho,as far as I can quess,a sys call would go via kernel to socket.xdd and then out to device driver in old mint for setting parameters to hardware.
That depends. Some are handled by the kernel, some by the socket driver, and some others are passed to the driver. The general interface is the same in all cases, but the interpretation of the extra argument depends on the type of call.
That would be for more modern kernels perhaps,since its built in today?,tho quess the driver_init() can fixup direct jumps into driver,hence bypassing the need for 'modern-style' programming ;)
This is interesting,think have to check up some more on my old stuff.
Post Reply

Return to “C / PASCAL etc.”