Mail Archives: djgpp/1999/06/15/12:54:07
| From: | "Christopher Nelson" <paradox AT gye DOT satnet DOT net>
|
| To: | <djgpp AT delorie DOT com>
|
| Subject: | FSEXT problem/question
|
| Date: | Mon, 14 Jun 1999 23:24:15 -0600
|
| Message-ID: | <01beb6ef$4f604220$LocalHost@thendren>
|
| MIME-Version: | 1.0
|
| X-Priority: | 3
|
| X-MSMail-Priority: | Normal
|
| X-Mailer: | Microsoft Outlook Express 4.71.1712.3
|
| X-MimeOLE: | Produced By Microsoft MimeOLE V4.71.1712.3
|
| Reply-To: | djgpp AT delorie DOT com
|
This is a multi-part message in MIME format.
------=_NextPart_000_0041_01BEB6BD.04C5D220
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Probably Eli, Nate, or DJ can best answer this question for me:
=20
I wrote a File System Extension for DJGPP using DJDEV2.02. This =
extension allows a programmer to treate memory as if it were a file. =
That way you can use the normal f{open/close/read/write/etc.} routines =
and have what is essentially a RAMDRIVE.
=20
It fully emulates the device, down to stat and fstat. The extension =
basically builds it's own mini-filesystem right in memory. To access =
the extension, files should be opened under "/dev/ramdrv/", which then =
triggers the open function into creating a ram-based file and taking =
control of it, rather than passing it along. All good and well. Here's =
the problem:
=20
According to the help file, extensions which fully emulate a device =
should use __FSEXT_alloc_fd to get a file descriptor, since they won't =
recieve one through DOS's normal gateway, that being logical since DOS =
has no "/dev/ramdrv" device. Unfortunately, instead of getting re-used, =
closed file handles are discarded. That means that a user may open only =
255-13 files in a session (not simulataneously, i mean ever. during the =
life of the program, the user may only open a ramdrv file 255-13 times. =
which means that you could open and close the same file 255-13 times, or =
something similiar, see?) and after that it dies because I get a -1 for =
the file descriptor.
=20
I realize that that happens because __FSEXT_alloc_fd only does a dup =
off the descriptor for the "nul" device, but isn't there anyway to reuse =
it? That seems to be a fairly huge problem. I can't see any extension =
being satisfactory with only being able to work 255-13 times. =20
=20
The only other option I saw was to allocate ONE descriptor, then =
allocate my own descriptors for each additional file. However, that =
does not work because I only get one bit of information from read and =
write, and that is the descriptor. It would be impossible for me to =
know WHICH file it was referring to if they were broken off from the =
main descriptor.
=20
Is there anything I can do? The close procedure for my extension is =
pretty simple, not that it matters anyway, since the same thing happens =
whether I want it to or not: (meaning that the _close function always =
closes the handle passed it, no matter what it is that I tell it.)
=20
int
mmf_close(int filedes)
{
__FSEXT_set_data(filedes, 0);
return(0);
}
And this is the entry in the handler:
case __FSEXT_close:
*rv =3D mmf_close(va_arg(args, int));
return(1);
break;
This is output from the testbench. The number to the far left is =
obviously the cycle, the number following 1: is the file handle obtained =
from fileno(test1_f) for the disk-based file. The number following the =
2: is the same thing for the ram-based file using fileno(test2_f):
0 (1:9 2:13)
1 (1:9 2:14)
2 (1:9 2:15)
3 (1:9 2:16)
4 (1:9 2:17)
5 (1:9 2:18)
6 (1:9 2:19)
7 (1:9 2:20)
8 (1:9 2:21)
9 (1:9 2:22)
10 (1:9 2:23)
11 (1:9 2:24)
12 (1:9 2:25)
13 (1:9 2:26)
14 (1:9 2:27)
15 (1:9 2:28)
16 (1:9 2:29)
17 (1:9 2:30)
18 (1:9 2:31)
19 (1:9 2:32)
20 (1:9 2:33)
as you can see, the descriptor slowly progresses up the ladder.
here's a little farther on:
226 (1:9 2:239)
227 (1:9 2:240)
228 (1:9 2:241)
229 (1:9 2:242)
230 (1:9 2:243)
231 (1:9 2:244)
232 (1:9 2:245)
233 (1:9 2:246)
234 (1:9 2:247)
235 (1:9 2:248)
236 (1:9 2:249)
237 (1:9 2:250)
238 (1:9 2:251)
239 (1:9 2:252)
240 (1:9 2:253)
241 (1:9 2:254)
242 (1:9 2:-1)
243 (1:9 2:-1)
244 (1:9 2:-1)
245 (1:9 2:-1)
246 (1:9 2:-1)
As you can imagine, this is somewhat annoying. Is there anything at all =
that I can do?
-=3D{C}=3D-
------=_NextPart_000_0041_01BEB6BD.04C5D220
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2> Probably Eli, Nate, or DJ can =
best answer=20
this question for me:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> I wrote a File =
System=20
Extension for DJGPP using DJDEV2.02. This extension allows a =
programmer to=20
treate memory as if it were a file. That way you can use the =
normal=20
f{open/close/read/write/etc.} routines and have what is essentially a=20
RAMDRIVE.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> It fully emulates =
the device,=20
down to stat and fstat. The extension basically builds it's own=20
mini-filesystem right in memory. To access the extension, files =
should be=20
opened under "/dev/ramdrv/", which then triggers the open =
function=20
into creating a ram-based file and taking control of it, rather than =
passing it=20
along. All good and well. Here's the problem:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> According to the =
help file,=20
extensions which fully emulate a device should use __FSEXT_alloc_fd to =
get a=20
file descriptor, since they won't recieve one through DOS's normal =
gateway, that=20
being logical since DOS has no "/dev/ramdrv" device. =20
Unfortunately, instead of getting re-used, closed file handles are=20
discarded. That means that a user may open only 255-13 files in a =
session=20
(not simulataneously, i mean ever. during the life of the program, =
the=20
user may only open a ramdrv file 255-13 times. which means that =
you could=20
open and close the same file 255-13 times, or something similiar, see?) =
and=20
after that it dies because I get a -1 for the file =
descriptor.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> I realize that =
that happens=20
because __FSEXT_alloc_fd only does a dup off the descriptor for the=20
"nul" device, but isn't there anyway to reuse it? That =
seems to=20
be a fairly huge problem. I can't see any extension being =
satisfactory=20
with only being able to work 255-13 times. </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> The only other =
option I saw=20
was to allocate ONE descriptor, then allocate my own descriptors for =
each=20
additional file. However, that does not work because I only get =
one bit of=20
information from read and write, and that is the descriptor. It =
would be=20
impossible for me to know WHICH file it was referring to if they were =
broken off=20
from the main descriptor.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> Is there anything =
I can=20
do? The close procedure for my extension is pretty simple, not =
that it=20
matters anyway, since the same thing happens whether I want it to or =
not:=20
(meaning that the _close function always closes the handle passed it, no =
matter=20
what it is that I tell it.)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>int<BR>mmf_close(int =
filedes)<BR>{<BR>=20
__FSEXT_set_data(filedes, 0);<BR> return(0);<BR>}</FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2><BR>And this is the entry in the=20
handler:</FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> case =20
__FSEXT_close:<BR> *rv =3D=20
mmf_close(va_arg(args, int));<BR> =20
return(1);<BR> =
break;</FONT> </DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>This is output from the testbench. The number =
to the far=20
left is obviously the cycle, the number following 1: is the file handle =
obtained=20
from fileno(test1_f) for the disk-based file. The number following =
the 2:=20
is the same thing for the ram-based file using=20
fileno(test2_f):<BR></FONT> </DIV>
<DIV><FONT size=3D2>0 (1:9 2:13)<BR>1 (1:9 2:14)<BR>2 (1:9 2:15)<BR>3 =
(1:9=20
2:16)<BR>4 (1:9 2:17)<BR>5 (1:9 2:18)<BR>6 (1:9 2:19)<BR>7 (1:9 =
2:20)<BR>8 (1:9=20
2:21)<BR>9 (1:9 2:22)<BR>10 (1:9 2:23)<BR>11 (1:9 2:24)<BR>12 (1:9 =
2:25)<BR>13=20
(1:9 2:26)<BR>14 (1:9 2:27)<BR>15 (1:9 2:28)<BR>16 (1:9 2:29)<BR>17 (1:9 =
2:30)<BR>18 (1:9 2:31)<BR>19 (1:9 2:32)<BR>20 (1:9 =
2:33)<BR></FONT> </DIV>
<DIV><FONT size=3D2>as you can see, the descriptor slowly progresses up =
the=20
ladder.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>here's a little farther =
on:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>226 (1:9 2:239)<BR>227 (1:9 =
2:240)<BR>228 (1:9=20
2:241)<BR>229 (1:9 2:242)<BR>230 (1:9 2:243)<BR>231 (1:9 2:244)<BR>232 =
(1:9=20
2:245)<BR>233 (1:9 2:246)<BR>234 (1:9 2:247)<BR>235 (1:9 2:248)<BR>236 =
(1:9=20
2:249)<BR>237 (1:9 2:250)<BR>238 (1:9 2:251)<BR>239 (1:9 2:252)<BR>240 =
(1:9=20
2:253)<BR>241 (1:9 2:254)<BR>242 (1:9 2:-1)<BR>243 (1:9 2:-1)<BR>244 =
(1:9=20
2:-1)<BR>245 (1:9 2:-1)<BR>246 (1:9 2:-1)<BR></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>As you can imagine, this is somewhat =
annoying. Is there anything at all that I can do?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 face=3D"" size=3D2> =20
-=3D{C}=3D-</FONT></DIV></BODY></HTML>
------=_NextPart_000_0041_01BEB6BD.04C5D220--
- Raw text -