From: "Christopher Nelson" To: Subject: FSEXT problem/question Date: Mon, 14 Jun 1999 23:24:15 -0600 Message-ID: <01beb6ef$4f604220$LocalHost@thendren> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01BEB6BD.04C5D220" 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

Probably Eli, Nate, or DJ can = best answer=20 this question for me:

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.

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:

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.

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.

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.

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.)

int
mmf_close(int = filedes)
{
=20 __FSEXT_set_data(filedes, 0);
return(0);
}

And this is the entry in the=20 handler:

case  =20 __FSEXT_close:
       *rv =3D=20 mmf_close(va_arg(args, int));
      =20 return(1);
       = break;

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):

0 (1:9 2:13)
1 (1:9 2:14)
2 (1:9 2:15)
3 = (1:9=20 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=20 2:21)
9 (1:9 2:22)
10 (1:9 2:23)
11 (1:9 2:24)
12 (1:9 = 2:25)
13=20 (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=20 ladder.

here's a little farther = on:

226 (1:9 2:239)
227 (1:9 = 2:240)
228 (1:9=20 2:241)
229 (1:9 2:242)
230 (1:9 2:243)
231 (1:9 2:244)
232 = (1:9=20 2:245)
233 (1:9 2:246)
234 (1:9 2:247)
235 (1:9 2:248)
236 = (1:9=20 2:249)
237 (1:9 2:250)
238 (1:9 2:251)
239 (1:9 2:252)
240 = (1:9=20 2:253)
241 (1:9 2:254)
242 (1:9 2:-1)
243 (1:9 2:-1)
244 = (1:9=20 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?

=20 -=3D{C}=3D-

------=_NextPart_000_0041_01BEB6BD.04C5D220--