On Thu, Jan 07, 2016 at 03:07:55AM -0800, Luigi Rizzo wrote: > I wonder how complex it would be to autogenerate > at least part of the various components required > when adding a syscall like this. There are two places in libc that need updating when adding a new syscall. One is the sys/Symbol.map. You add the syscall name in the right block, and since the correspondence between syscall and version is needed for autogeneration, the autogeneration would not save you any work.
Another part, which was done wrong in the patch, is the handling of the cancellable syscalls. For each cancellation point, the behaviour is very specific. This, and the fact that there are approximately two dozens of cancellable syscalls among ~500 total, make any sort of automation more complex than no automation at all. And note that in the current proposal, just doing loop in libc would manage this stuff correctly. If protocols become smarter and provide the mm- variants, then the syscalls would make more sense, and the perceived complexity of the libc changes would be invisible. > > It looks like the number of places to touch (see chunks > below) and the ordering constraints make the manual process very prone > to errors. Well, you need to understand what you do. The placess to fill are not formal or arbitrary, there are choices that affect behaviour and correctness. > > This said, it might be nice to add some explanation > in the various places, e.g. Symbol.map could do > with a comment describing the meaning of the various > groups FBSD_1.0 FBSD_1.1 FBSDprivate_1.0 and so on. Definitely. Look at libc/Versions.def. There is no explanation for cancellation stuff, but most of it follows from the specification. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
