Thanks Mike, and sorry for late responce,
I basically understand your comment. I think the code clean-up
is important befor committing. However, as you pointed out, I
would like to consider structure of my code for according the
treatment of device on -current on going. I basically respect
current structure already implemented and USB experience could
be used for IEEE1394. I have not understood NEWBUS designe
architecture and I have watched the architecture in the source
only. (Someonelet me know the pointer!!)
After investigating the archtecture, I will decide the new
structure of IEEE1394.
[EMAIL PROTECTED]
From: Mike Smith <[EMAIL PROTECTED]>
Subject: Re: IEEE1394 driver system for -current
Date: Thu, 24 Aug 2000 19:33:02 -0700
Message-ID: <[EMAIL PROTECTED]>
msmith>
msmith> There are several things that need to be fixed. I'm not going to be nice
msmith> about the code, because it needs some major work before it is ready, but
msmith> I do think that it is worth using your code (and your skills) in some
msmith> form.
msmith>
msmith> 1) The code is very messy. This makes it hard to read. It needs to be
msmith> reformatted before committing to reduce whitespace/style changes
msmith> afterwards.
msmith>
msmith> 2) There are a lot of "magic numbers" (numeric values for registers and
msmith> so forth) rather than defined constants. This makes it hard to work
msmith> out what parts of the code are doing.
msmith>
msmith> 3) The code lacks structure. There are some very clear divisions that
msmith> should be made between the various components in the 1394 stack, and
msmith> these are not being made. Fixing this will involve moving a lot of
msmith> code around, and should be done before the code is committed.
msmith>
msmith> 1394 can be looked at as being quite similar to USB (the predominant
msmith> interface model is OHCI, also used for USB). The obvious software
msmith> components are:
msmith>
msmith> a) Host adapter driver (eg. TI Lynx, NEC, Adaptec, etc.)
msmith> b) Generic 1394 layer
msmith> c) Peripheral/protocol driver layer (eg. DV, CAM shim, etc)
msmith> c') Layered peripheral/protocol driver layer
msmith>
msmith> The interface between layers a) and b), and between layers b) and c)
msmith> and between layers c) and c') should all be clearly defined. Using
msmith> newbus and defining these interactions in terms of parent-child
msmith> relationships and bus methods will make this very easy.
msmith>
msmith> Having said so many cruel things about your code, it's clear that you've
msmith> spent a lot of time making your stack work, and during that time you must
msmith> have accumulated a lot of experience with these peripherals. I understand
msmith> that Warner has proposed you be granted CVS commit access in order to work
msmith> on your code in the FreeBSD CVS repository, and I'm in favour of this. I
msmith> would, however, like to see the above issues addressed before the initial
msmith> import.
msmith>
msmith> One option that you might want to consider is working with Bill Paul on
msmith> the cleanup and restructuring process. Bill has a lot of experience with
msmith> network-like peripherals, and with the way in which we like things to be
msmith> done. In combination with your experience with 1394 in general, I think
msmith> this would result in some very good and useful code. I've already spoken
msmith> to Bill about this, and he seemed interested. (Apologies if I'm dumping
msmith> you in it here, pal. 8)
msmith>
msmith> In summary, then, I would encourage you to consider the points above, and
msmith> engage in some discussion (either on the -arch list or on a new
msmith> freebsd-1394 list) about how to go about reorganising and cleaning up your
msmith> code ready for committing as soon as practical.
msmith>
msmith> Regards,
msmith>
msmith>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
