Re: [RFC] 0/11 fanotify: fscking all notifiction and file access system (intended for antivirus scanning and file indexers)

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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, ....);
	close(fd);

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