File Descriptor passing fun

File Descriptor passing fun

[David E Euresti]

Hi,
	I wanted to submit my code to pass file descriptors in cygwin.

typedef u_int	SOCKET;
#include<windows.h>
#include<io.h>
#include <sys/cygwin.h>
#define DEADBEEF 3735928559
//extern void sfs_warn (const char *fmt, ...) __attribute__ ((format
(printf, 1, 2)));
const char *windows_device_names[] =
{
  NULL,
  "\\dev\\console",
  "conin",
  "conout",
  "\\dev\\ttym",
  "\\dev\\tty%d",
  "\\dev\\ptym",
  "\\\\.\\com%d",
  "\\dev\\pipe",
  "\\dev\\piper",
  "\\dev\\pipew",
  "/dev/udp",
  "\\dev\\windows",
  NULL, NULL, NULL,
  "\\dev\\disk",
  "\\dev\\fd%d",
  "\\dev\\st%d",
  "nul",
  "\\dev\\zero",
  "\\dev\\%srandom",
  "\\dev\\mem",
  "\\dev\\clipboard",
  "\\dev\\dsp"
};
struct passfd {
  unsigned int uiMagic;
  DWORD dwProcessID;
  HANDLE hHandle;
  BOOL bBinary;
  BOOL bRead;
  BOOL bWrite;
  DWORD dwDevice;
};
int getmode (int fd);
int
parse_fdp(struct passfd *fdp)
{
  BOOL bOk;
  int fd;
  int gread, gwrite;
  HANDLE hOther, hThis = NULL;
  HANDLE h = NULL;
  //sfs_warn("Received  ProcId %d, Handle 0x%x,
Device:%d\n",fdp->dwProcessID, fdp->hHandle, fdp->dwDevice);
  hOther = OpenProcess(PROCESS_DUP_HANDLE, FALSE, fdp->dwProcessID);
  hThis = OpenProcess(PROCESS_DUP_HANDLE, FALSE, GetCurrentProcessId());
  bOk = DuplicateHandle(hOther, fdp->hHandle, hThis,
			  &h, 0, TRUE, DUPLICATE_SAME_ACCESS);
  if (!bOk) {
	  //sfs_warn("Error in Duplicate Handle");
    return -1;
  }
  CloseHandle(hOther);
  CloseHandle(hThis);
  //sfs_warn("It is a %s type handle",(char*)
windows_device_names[fdp->dwDevice]);
  gread = (fdp->bRead ? GENERIC_READ : 0);
  gwrite = (fdp->bWrite ? GENERIC_WRITE : 0);
  fd = cygwin32_attach_handle_to_fd((char*)
windows_device_names[fdp->dwDevice], -1, h,
		fdp->bBinary, gread | gwrite);
  //sfs_warn("attach handle %d\n", fd);
  return fd;
}

ssize_t
writevfd (int fd, const struct iovec *iov, int iovcnt, int wfd)
{
  struct passfd fdp[1];
  struct stat sbuf;
  int tot = 0;
  int i, ret;
  char *buf,*p;
  struct sockaddr sa;
  int sal = sizeof (sa);
  //sfs_warn("Sending fd\n");
  fstat(wfd, &sbuf);
  fdp->uiMagic = DEADBEEF;
  fdp->dwProcessID = GetCurrentProcessId();
  fdp->hHandle = (HANDLE) get_osfhandle(wfd);
  fdp->bBinary = getmode(wfd);
  fdp->bRead = sbuf.st_mode & S_IRUSR;
  fdp->bWrite = sbuf.st_mode & S_IWUSR;
  fdp->dwDevice = sbuf.st_dev>>8;
  if ((fdp->dwDevice == 0) && getpeername (fd, &sa, &sal) == 0)
	  fdp->dwDevice = 11;  // CYGWIN magic number.
  //sfs_warn("Sending fd: %d, ProcId %d, Handle 0x%x, Device:%d\n",wfd,
fdp->dwProcessID, fdp->hHandle, fdp->dwDevice);
  for(i = 0; i < iovcnt; ++i)
    tot += iov[i].iov_len;
  buf = (char *) malloc(tot+sizeof(struct passfd));
  if (tot != 0 && buf == NULL) {
    errno = ENOMEM;
    return -1;
  }
  p = buf;
  memcpy(p, fdp, sizeof(struct passfd));
  p+= sizeof(struct passfd);
  for (i = 0; i < iovcnt; ++i) {
    memcpy (p, iov[i].iov_base, iov[i].iov_len);
    p += iov[i].iov_len;
  }
  ret = send (fd, buf, tot+sizeof(struct passfd), 0);
  free (buf);
  if (ret >= sizeof(struct passfd))
    return ret-sizeof(struct passfd);
  else
    return ret;
}

ssize_t
readvfd (int fd, const struct iovec *iov, int iovcnt, int *rfdp)
{
  int i;
  struct passfd fdp[1];
  int ret, nb;
  size_t tot = 0;
  char *buf, *p;

  //sfs_warn("Read fd\n");
  for(i = 0; i < iovcnt; ++i)
    tot += iov[i].iov_len;
  buf = (char *) malloc(tot+sizeof(struct passfd));
  if (tot != 0 && buf == NULL) {
    errno = ENOMEM;
    return -1;
  }
  nb = ret = recv (fd, buf, tot+sizeof(struct passfd), 0);
  p = buf;
  if (nb >= sizeof(struct passfd)) {
    memcpy(fdp, buf, sizeof(struct passfd));
    if (fdp->uiMagic == DEADBEEF) {
		//sfs_warn("Actually an fd!\n");
      p += sizeof(struct passfd);
      nb -= sizeof(struct passfd);
      *rfdp = parse_fdp(fdp);
      ret = nb;
    }
  }
  while (nb > 0) {
    ssize_t cnt = min(nb, iov->iov_len);

    memcpy (iov->iov_base, p, cnt);
    p += cnt;
    nb -= cnt;
    ++iov;
  }
  free(buf);

  if (*rfdp >= 0 && ret == 0) {
    ret = -1;
    errno = EAGAIN;
  }
  return ret;
}


Unfortunately it suffers from lineup issues.  If you try to send data,
then a file descriptor, then more data, the reader will get lost and not
find any file descriptor and return data that you never really sent.  If
anybody has any other ideas about how to do this, let me know.

Once it's fixed I'm sure this code will be useful in cygwin.

David


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

mkcramfs porting done - device file issues....

[gmx]

Hello CygWinners,

first, please ignore my last mail - i solved the porting problem of mkcramfs with the
help of some people - it wasn't hard to solve.  We can now build linux cramfs-filesystems under cygwin.
If there is any interest in putting mkcramfs.exe into the cygwin-distribution - pleasy tell me and i will
send it to you...

but i have run into one  serious problem:
If i untar a file, which contains devices, it doesn't work under cygwin.
It's clear that i just can`t transfer device-nodes from linux and use them under cygwin, because there
maybe no "equivalent" for a linux device on the windows platform , but since devices are just files containing/referencing
"numbers", i.e.  minor,major device numbers, i don`t understand, why the files
cannot be created.
Under Linux i have devices under /dev which possibly point to 'nirvana' (because there is no appropriate
kernel feature/mod). Why should't i have such "dummy-dev`s" under cygwin ?

Isn't this "feature" implemented yet and can it be easily implemented ?
Are there any people also would like to see this ? i'd like to have  the ability to untar a file containing
/dev structure under cygwin and create a cramfs from that. Maybe if no other people need this feature, i see some
possibility to include a "create-device-node-in-cramfs-via-input-from-textfile"-Feature in mkcramfs#, but that's
not really nice, i think...
Since there is mknod in cygwin, I think support for devices could be 'on it`s way' - but can someone
give me further information regarding this ?
thank you
bye
Roland


tar xvf netstation-08.tar
netstation-0.8/pkg-tree/base/bin/mdetect
netstation-0.8/pkg-tree/base/dev/
netstation-0.8/pkg-tree/base/dev/console
tar: netstation-0.8/pkg-tree/base/dev/console: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/md0
tar: netstation-0.8/pkg-tree/base/dev/md0: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/mem
tar: netstation-0.8/pkg-tree/base/dev/mem: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/null
tar: netstation-0.8/pkg-tree/base/dev/null: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/psaux
tar: netstation-0.8/pkg-tree/base/dev/psaux: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/ram0
tar: netstation-0.8/pkg-tree/base/dev/ram0: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/tty




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: mkcramfs porting done - device file issues....

[Christopher Faylor]

On Mon, Apr 29, 2002 at 03:52:27AM +0200, gmx wrote:
>Under Linux i have devices under /dev which possibly point to 'nirvana'
>(because there is no appropriate kernel feature/mod).  Why should't i
>have such "dummy-dev`s" under cygwin ?

Cygwin doesn't have major and minor device numbers.

>Isn't this "feature" implemented yet and can it be easily implemented ?

It isn't implemented and it would be difficult to implement.  Sorry.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: mkcramfs porting done - device file issues....

[Corinna Vinschen]

On Tue, May 28, 2002 at 11:12:22PM -0400, Christopher Faylor wrote:
> On Mon, Apr 29, 2002 at 03:52:27AM +0200, gmx wrote:
> >Under Linux i have devices under /dev which possibly point to 'nirvana'
> >(because there is no appropriate kernel feature/mod).  Why should't i
> >have such "dummy-dev`s" under cygwin ?
> 
> Cygwin doesn't have major and minor device numbers.

That's not quite correct.

Cygwin is using major and minor device numbers but there's nothing
like a device node in the filesystem.  The handling of major and
minor device numbers is purely internally.  What you *can* do is,
create a /dev directory and create (in Windows Explorer) files in
it which are named exactly as the devices known to Cygwin.  E. g.
if you created a file called `st0' - the name of the first tape
device in the system - then you can call `ls -l /dev' and you will
see:

  total 0
  crw-rw-rw-    1 root     root      18,   0 May 29 10:05 st0

The cause is that the handling of devices overrides the path
handling.  But that's *only* possible for device names known
to Cygwin.

> >Isn't this "feature" implemented yet and can it be easily implemented ?
> 
> It isn't implemented and it would be difficult to implement.  Sorry.

We discussed to implement something like loadable device drivers
already two years ago and which could be implemented using device
nodes.  It's not implemented though...  no time, no volunteers.

What would be possible is to add only the device nodes.  They could
be implemented like symlinks but I'm reluctant to add these to
Cygwin as long as there's no mechanism to actually use them.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

AW: mkcramfs porting done - device file issues....

[gmx]

Hi Corinna, 
thanks for reply.

>minor device numbers is purely internally.  What you *can* do is,
>create a /dev directory and create (in Windows Explorer) files in
>it which are named exactly as the devices known to Cygwin.  E. g.

regarding this , what's the purpose of mknod.exe in cygwin then  ???


>What would be possible is to add only the device nodes.  They could
>be implemented like symlinks 
Yes - that's what had come to my mind...

>but I'm reluctant to add these to Cygwin as long as there's no mechanism 
>to actually use them.
:(((
maybe reading them, ls'ing them, tar'ing them or creating a cramfs from 
them could be a mechanism, i think.... ;) Though, there may be not many 
people out there, who actually need such feature. I think it would be nice, 
if it's "in there" just for "completeness" or "posix compliance".... or, maybe, 
just to get rid of those annoying:
tar: netstation-0.8/pkg-tree/base/dev/console: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/md0
tar: netstation-0.8/pkg-tree/base/dev/md0: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/mem
tar: netstation-0.8/pkg-tree/base/dev/mem: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/null.....

;)))

i would do that stuff myself,if i could - so it completely depends on the goodwill
of some "wizards" like you ...  :(

regards
Roland



Cygwin is using major and minor device numbers but there's nothing
like a device node in the filesystem.  The handling of major and
minor device numbers is purely internally.  What you *can* do is,
create a /dev directory and create (in Windows Explorer) files in
it which are named exactly as the devices known to Cygwin.  E. g.
if you created a file called `st0' - the name of the first tape
device in the system - then you can call `ls -l /dev' and you will
see:

  total 0
  crw-rw-rw-    1 root     root      18,   0 May 29 10:05 st0

The cause is that the handling of devices overrides the path
handling.  But that's *only* possible for device names known
to Cygwin.

> >Isn't this "feature" implemented yet and can it be easily implemented ?
> 
> It isn't implemented and it would be difficult to implement.  Sorry.

We discussed to implement something like loadable device drivers
already two years ago and which could be implemented using device
nodes.  It's not implemented though...  no time, no volunteers.

What would be possible is to add only the device nodes.  They could
be implemented like symlinks but I'm reluctant to add these to
Cygwin as long as there's no mechanism to actually use them.

Corinna



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

AW: mkcramfs porting done - device file issues....

[gmx]

Hi Corinna, 
thanks for reply.

>minor device numbers is purely internally.  What you *can* do is,
>create a /dev directory and create (in Windows Explorer) files in
>it which are named exactly as the devices known to Cygwin.  E. g.

regarding this , what's the purpose of mknod.exe in cygwin then  ???


>What would be possible is to add only the device nodes.  They could
>be implemented like symlinks 
Yes - that's what had come to my mind...

>but I'm reluctant to add these to Cygwin as long as there's no mechanism 
>to actually use them.
:(((
maybe reading them, ls'ing them, tar'ing them or creating a cramfs from 
them could be a mechanism, i think.... ;) Though, there may be not many 
people out there, who actually need such feature. I think it would be nice, 
if it's "in there" just for "completeness" or "posix compliance".... or, maybe, 
just to get rid of those annoying:
tar: netstation-0.8/pkg-tree/base/dev/console: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/md0
tar: netstation-0.8/pkg-tree/base/dev/md0: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/mem
tar: netstation-0.8/pkg-tree/base/dev/mem: Cannot mknod: Function not implemented
netstation-0.8/pkg-tree/base/dev/null.....

;)))

i would do that stuff myself,if i could - so it completely depends on the goodwill
of some "wizards" like you ...  :(

regards
Roland



Cygwin is using major and minor device numbers but there's nothing
like a device node in the filesystem.  The handling of major and
minor device numbers is purely internally.  What you *can* do is,
create a /dev directory and create (in Windows Explorer) files in
it which are named exactly as the devices known to Cygwin.  E. g.
if you created a file called `st0' - the name of the first tape
device in the system - then you can call `ls -l /dev' and you will
see:

  total 0
  crw-rw-rw-    1 root     root      18,   0 May 29 10:05 st0

The cause is that the handling of devices overrides the path
handling.  But that's *only* possible for device names known
to Cygwin.

> >Isn't this "feature" implemented yet and can it be easily implemented ?
> 
> It isn't implemented and it would be difficult to implement.  Sorry.

We discussed to implement something like loadable device drivers
already two years ago and which could be implemented using device
nodes.  It's not implemented though...  no time, no volunteers.

What would be possible is to add only the device nodes.  They could
be implemented like symlinks but I'm reluctant to add these to
Cygwin as long as there's no mechanism to actually use them.

Corinna



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: mkcramfs porting done - device file issues....

[Corinna Vinschen]

On Thu, May 30, 2002 at 12:41:56AM +0200, gmx wrote:
> Hi Corinna, 
> thanks for reply.
> 
> >minor device numbers is purely internally.  What you *can* do is,
> >create a /dev directory and create (in Windows Explorer) files in
> >it which are named exactly as the devices known to Cygwin.  E. g.
> 
> regarding this , what's the purpose of mknod.exe in cygwin then  ???

There is none.  It's just in there since it's part of fileutils.

> >What would be possible is to add only the device nodes.  They could
> >be implemented like symlinks 
> Yes - that's what had come to my mind...

I did actually implement them some 2 years ago.  But since we don't
have this loadable driver mechanism, it's still not clear if it's
the way to go at all.  Another option would be to load the driver
modules which then get major device numbers only inside of Cygwin
and which maintain their minor device numbers by themselves.  This
proposal would drop the need for device nodes completely.

I hope this makes clear why we don't want to implement something
which isn't filled with life but which *could* block development
at some later point if it turns out that another way is the better
one.

Even if that requires some more work, I'd suggest to port cramfs
to Cygwin by either drop the dependency for the major/minor number
stuff or by implementing it as fhandler inside of Cygwin.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/