Adding shared memory implementation

Mikael Lund Jepsen, ICCC mlj at iccc.dk
Tue Jan 27 09:47:35 UTC 2009


Bernhard Reutner-Fischer wrote:
> This can simply be dropped into the proper tests/ subdir, no?
>   
I'm not yet familiar with the test suite, so I had not considered 
putting it in there, but I think it is definitely a good idea.
I just looked briefly at the (quite elaborate) test skeleton and a few 
of the existing tests, but I did not see any unique pattern or 
requirements to follow,
so unless there are any special requirements to fit into the test 
environment, I guess it could just be dropped in...
Please let me know if I need to change the test code.
>> diff --git a/librt/shm_open.c b/librt/shm_open.c
>> new file mode 100644
>> index 0000000..cb92c3a
>> --- /dev/null
>> +++ b/librt/shm_open.c
>> @@ -0,0 +1,48 @@
>> +/* shm_open - open a shared memory file */
>> +
>> +/* Copyright 2002, Red Hat Inc. */
>> +
>> +#include <sys/types.h>
>> +#include <sys/mman.h>
>> +#include <unistd.h>
>> +#include <string.h>
>> +#include <fcntl.h>
>> +#include <limits.h>
>> +
>> +int
>> +shm_open (const char *name, int oflag, mode_t mode)
>> +{
>> +  int fd;
>> +  char shm_name[PATH_MAX+20] = "/dev/shm/";
>>     
> That's a bit excessive, don't you think.
>   
Yes I do :-), but the man page does mention PATH_MAX as the upper legal 
length of names to pass (even though neither the newlib or glibc returns 
the mentioned ENAMETOOLONG).

I tried looking around a bit for similar functions constructing paths. 
Using FILENAME_MAX as in tempnam is just as bad, size wise.
As I see it we can either impose a special (shorter) name lenght for 
uclibc or dynamically allocate a buffer with an appropriate size.
Any preferences?
>> +
>> +  /* Construct the filename.  */
>> +  while (name[0] == '/')
>> +    ++name;
>> +
>> +  /* create special shared memory file name and leave enough space to
>> +     cause a path/name error if name is too long */
>> +  strlcpy (shm_name + 9, name, PATH_MAX + 10);
>>     
> sounds like a BSD extension.
>   
Possibly - I'm not a BSD guy ;-)
>> +
>> +  fd = open (shm_name, oflag, mode);
>> +
>> +  if (fd != -1)
>> +    {
>> +      /* once open we must add FD_CLOEXEC flag to file descriptor */
>> +      int flags = fcntl (fd, F_GETFD, 0);
>> +
>> +      if (flags >= 0)
>> +        {
>> +          flags |= FD_CLOEXEC;
>> +          flags = fcntl (fd, F_SETFD, flags);
>>     
>
> I would write this as
> 	if (flags >= 0)
> 		flags = fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
>
> but that shouldn't make a difference.
>   
I would also - and since it seems we are going down a different path 
than the original newlib implementation anyway, I have changed this.
> please look at the size(1) output for those two files and fix them.
> TIA,
> Bernhard
>   
>> +        }
>> +
>> +      /* on failure, just close file and give up */
>> +      if (flags == -1)
>> +        {
>> +          close (fd);
>> +          fd = -1;
>> +        }
>> +    }
>> +
>> +  return fd;
>> +}
>> diff --git a/librt/shm_unlink.c b/librt/shm_unlink.c
>> new file mode 100644
>> index 0000000..cf259c6
>> --- /dev/null
>> +++ b/librt/shm_unlink.c
>> @@ -0,0 +1,28 @@
>> +/* shm_unlink - remove a shared memory file */
>> +
>> +/* Copyright 2002, Red Hat Inc. */
>> +
>> +#include <sys/types.h>
>> +#include <sys/mman.h>
>> +#include <unistd.h>
>> +#include <string.h>
>> +#include <limits.h>
>> +
>> +int
>> +shm_unlink (const char *name)
>> +{
>> +  int rc;
>> +  char shm_name[PATH_MAX+20] = "/dev/shm/";
>> +
>> +  /* Construct the filename.  */
>> +  while (name[0] == '/')
>> +    ++name;
>> +
>> +  /* create special shared memory file name and leave enough space to
>> +     cause a path/name error if name is too long */
>> +  strlcpy (shm_name + 9, name, PATH_MAX + 10);
>> +
>> +  rc = unlink (shm_name);
>> +
>> +  return rc;
>> +}
>>     

-- 


Mikael Lund Jepsen, Software Engineer

ICCC A/S, Telegrafvej 5 B, 2750 Ballerup, DENMARK

Phone: 	+45 44 86 04 00
Direct: 	+45 44 86 04 25
Fax: 	+45 44 86 03 99
  	 
Email: 	mlj at iccc.dk <mailto:mlj at iccc.dk>
Web: 	www.iccc.dk <http://www.iccc.dk>



More information about the uClibc mailing list