# Device drivers: some questions about d_close



## ~/rs (Oct 27, 2016)

Hi,

I am porting just for fun a Linux char device of mine to FreeBSD. However, I am having some issues with the "d_close". In Linux the routines related with file closing are or at least should be executed by "release".

So, this device driver specifically admits N open() calls... If the process performs an open() call N + 1 it will fail until that at least one close() call is done. In this case, when the close() call is done one "slot" will be freed in order to admit that N + 1 open() call and it will work fine.

However, on FreeBSD I observed that the d_close() is only effectively called when I call it N times (I previously opened it N times).

My question is: Is there some way of executing (to enforce the kernel "trap") the d_close() even lacking N - 1 calls to be accomplished? A way of making the kernel forget about this kind of "reference count"...

Here goes some pseudo code of the unit test that are breaking on FreeBSD:


```
(...)
    const int open_nr = 10;
    int fd[open_nr];
    int f

    for (f = 0; f < open_nr; f++) {
        fd[f] = open("/dev/test", O_RDWR);
        ASSERT(fd[f] > -1);
    }
      
    // This next one syscall should fail because all "slots" were consumed by the last loop
    f = open("/dev/test", O_RDWR);
    ASSERT(f == -1);
      
    ASSERT(close(fd[0]) == 0); // This is ok, and by my understanding It should release the related "fd#" instance. On Linux it is okay.
    
    // Here fails on FreeBSD (the test only passes if I call close(fd[f]) for f = 0 until open_nr).
    f = open("/dev/test", O_RDWR);
    ASSERT(f > -1);
(...)
```

Thanks in advance!
--


----------



## ~/rs (Oct 27, 2016)

Hi everybody,

I found a way, after doing some research I discovered this "magical" function: *devfs_set_cdevpriv(void *priv, d_priv_dtor_t *dtr)*.

Now it looks be working fine!

Thanks anyway!
--


----------

