On Tue, 31 Mar 2015 15:02:24 -0700 josh@xxxxxxxxxxxxxxxx wrote: > > This would appear to assume that a clonefd_info structure is the only > > thing that will ever be read from this descriptor. It seems to me that > > there is the potential for, someday, wanting to be able to read and write > > other things as well. Should this structure be marked with type and > > length fields so that other structures could be added in the future? > > I don't think it makes sense for a caller to get an arbitrary structure > on read(), and have to figure out what they got and ignore something > they don't understand. Instead, I think it makes more sense for the > caller to say "Hey, here's a flag saying I understand the new thing, go > ahead and give me the new thing". So, for instance, if you want to > receive SIGSTOP/SIGCONT messages for child processes through this > descriptor, we could add a flag for that. The flag is fine, but, once we have set that flag saying we want those messages, how do we know which type of structure we've gotten? That's the piece of the puzzle I'm missing, sorry if I'm being overly slow. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
