Note CC list changed..

On Thu, 13 Sep 2001, John Baldwin wrote:

> On 13-Sep-01 Julian Elischer wrote:
> > Why are you doing this?
> > having pointers to threads that are calle proc is going to be REALLY 
> > confusing!
> > 
> > All vop operations will have threads (do)
> > so why are you puting proc structures on them?

> Because the code claims to be shared with NetBSD and they dont have struct
> thread.  However, as we talked on the phone, if portability with NetBSD is no
> longer a concern, then this is moot.

#define proc threadB

is a REALLY bad choice of how to do this..

If You REALLY MUST do this..
#ifdef __FreeBSD__
#define OS_THREAD thread  
#define OS_THREAD proc

at least that way it will be obvious in the code that it's not a proc
in FreeBSD.

But as I said on the phone, NetBSD are making hteir own changes
in these files  without ifdeffing, so the minimal diff changes (easy to
see and understand) you are removing simply massively obscure
the code for FreeBSD.

We have a struct proc, so to define proc to actually be a thread
is not just obscure, it's possitively misleading.

We could add general macros for compatibility
but they should probably go in a central place so that they can be used in
multiple places.

If you really wanted to go overboard, we could 
#ifdef __FreeBSD__
typedef struct thread *vop_thread_arg;
#define V_TD_PROC(dta) ((dta)->td_proc)
typedef struct proc *vop_thread_arg;
#define V_TD_PROC(dta) (dta)

or some similar set of macros but I'm uncomfortable about 
obfuscating the code and even more unhappy about making it plain

> -- 
> John Baldwin <[EMAIL PROTECTED]> --
> PGP Key:
> "Power Users Use the Power to Serve!"  -

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to