Fix seq namespace collisions

[kmacy]

Summary

sys/seq.h is included in a couple of core system headers where it really doesn't need to be. This is a problem because it declares functions whose names collide with linux declarations. In practice the linux implementations will have to be named differently, but importing seq.h everywhere only makes that messier.

Test Plan

N/A

[mjg]

Turning fd_modiied into an actual function call makes it unnecessarily more expensive to use and the removal of seq_t type makes it harder to change later.

In general, if there is a conflict, I would suggest changing the name instead. For instance, a totally acceptable name for me would be 'sqc' ("seqeuence counter").

[kmacy]

In D6590#160765, @mjg wrote:

Turning fd_modiied into an actual function call makes it unnecessarily more expensive to use and the removal of seq_t type makes it harder to change later.

In general, if there is a conflict, I would suggest changing the name instead. For instance, a totally acceptable name for me would be 'sqc' ("seqeuence counter").

@mjg As detailed in the description the problem is that the functions in seq.h collide with those in linux (e.g. seq_read). You've essentially caused *everything* in sys to include seq.h when it's only used in few places. What I'd like is to be able to include filedesc.h and _vm_domain.h without including seq.h. Your suggestions don't address this.

Thanks in advance.

[kmacy]

Changing fd_modified to a macro would allow us to include filedesc.h while only requiring fd_modified consumers to include seq.h.

The other problem is the use of seq_t or scq_t in the function and structure declaration. We could fix that by moving that typedef out of seq.h in to one of param.h/systm.h/cdefs.h.

Are you amenable to that?