[lkml]   [2008]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] 0/11 fanotify: fscking all notifiction and file access system (intended for antivirus scanning and file indexers)
> struct fan_sockaddr {
> int version;
> unsigned int mask;
> pid_t pid;
> pid_t tgid;
> int f_flags;
> }
> so this will be a binary interface for metadata. Sending the metadata
> about the open fd up the sockaddrs is very slick, but not easily
> extended that I can see. Guess we need to get the metadata right the
> first time.

Usual way socket stuff covers for that is to stick

unsigned int __unused[8];

or similar on the end...

> PF_FAN system. This new fd from connect can then take commands using
> either sendmsg() or setsockopt() or really anything since it doesn't
> have a 'real file' on the backend.

That is the normal socket approach. Eg in traditional BSD interfaces for
IP routing you created an AF_INET socket and frobbed with it.

> So the alternative would be that I could make ALL listener->kernel
> communication go over the fd that came from connect(). Setting a

Probably a lot saner

> includes types and lens. Is is it bad to have a fd whose only
> implemented function is setsockopt?

Not really. Lots of socket types have operations that are essentially

fd = socket(...)
ioctl(fd, ....);

or similar. Traditionally ioctl is used for system changing stuff but
that is just tradition.

 \ /
  Last update: 2008-10-02 22:53    [W:0.158 / U:2.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site