| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 198.1 | Re: resurrecting file which had a former life | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jul 08 1993 11:20 | 19 |
| Date Of Receipt: 8-JUL-1993 10:12:18.27
From: FLUME::jmcg "Jim McGinness"
To: [email protected], [email protected]
CC:
Subj: Re: resurrecting file which had a former life
The file doesn't show up in the DEFUNCT list for agosminor or agosmaint,
nor is it present in the SNAPSHOT file of agosminor, agosmaint, or
alpha.bl012, so you should just be able to bci and bsubmit it.
On the other hand, are you sure this file should be in kernel/sys?
There's already a kernel/io/cam/cdrom.h and it would be unfortunate to
have two kernel header files with the same name because of the way VPATH
tends to mush up the process of figuring out which one gets included.
The HISTORY section of kernel/io/cam/cdrom.h indicates it used to live
in kernel/sys.
-- jmcg
|
| 198.2 | Re: resurrecting file which had a former life | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jul 08 1993 12:23 | 20 |
| Date Of Receipt: 8-JUL-1993 10:31:29.65
From: ABYSS::"[email protected]" "John Kohl"
To: [email protected], [email protected]
CC:
Subj: Re: resurrecting file which had a former life
> Date: Thu, 8 Jul 1993 10:12:21 -0400
> From: [email protected] (Jim McGinness)
> On the other hand, are you sure this file should be in kernel/sys?
Well, unfortunately, the RRIP and XCDR specs says <sys/cdrom.h> needs to
find the include file. If there's some other place to put it in the
hierarchy and have it end up in /usr/include/sys/cdrom.h on the export
tree and final kit, I'd be willing to do so.
[the new contents are RRIP and XCDR related, not at all related to the
different <io/cam/cdrom.h>]
John
|
| 198.3 | Re: resurrecting file which had a former life | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jul 08 1993 12:23 | 27 |
| Date Of Receipt: 8-JUL-1993 11:06:31.07
From: FLUME::jmcg "Jim McGinness"
To: flume::jtkohl
CC: flume::buildhelp, flume::cascio, flume::spt
Subj: Re: resurrecting file which had a former life
> Well, unfortunately, the RRIP and XCDR specs says <sys/cdrom.h> needs to
> find the include file. If there's some other place to put it in the
> hierarchy and have it end up in /usr/include/sys/cdrom.h on the export
> tree and final kit, I'd be willing to do so.
>
> [the new contents are RRIP and XCDR related, not at all related to the
> different <io/cam/cdrom.h>]
A SYMLINK directive in the right place can cause /usr/include/sys/cdrom.h
to point to /usr/include/io/cam/cdrom.h, so that's not necessarily a
problem. If the standard says the name of the file is sys/cdrom.h then
that's the name we have to use, but how restrictive is it on what
the contents of the file must be? You may need to check with the
wizards of Namespace Pollution to see what has to be done (try Dave
Metsky).
[These issues should have been resolved already for a project that has
filed (and been granted) an exception request.]
-- jmcg
|
| 198.4 | Re: resurrecting file which had a former life | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jul 08 1993 15:33 | 45 |
| Date Of Receipt: 8-JUL-1993 13:52:06.94
From: ABYSS::jtkohl "John Kohl"
To: abyss::jmcg
CC: abyss::buildhelp, abyss::cascio, abyss::spt
Subj: Re: resurrecting file which had a former life
> Date: Thu, 8 Jul 1993 10:12:21 -0400
> From: [email protected] (Jim McGinness)
> There's already a kernel/io/cam/cdrom.h and it would be unfortunate to
> have two kernel header files with the same name because of the way VPATH
> tends to mush up the process of figuring out which one gets included.
For the present, this seems not to be a problem, as all files which
include kernel/io/cam/cdrom.h use lines like this:
#include <io/cam/cdrom.h>
which wouldn't get <sys/cdrom.h> (and indeed, I can build a BINARY tree
just fine with both cdrom.h files in place). I did see the relocated
<io/cam/cdrom.h>, but I didn't think it likely that two cdrom.h's might
cause troubles.
>If the standard says the name of the file is sys/cdrom.h then
>that's the name we have to use, but how restrictive is it on what
>the contents of the file must be?
RRIP specifies some contents; XCDR (to be supported in Gold) specifies
other contents. Neither precludes the inclusion of additional
declarations/definitions in <sys/cdrom.h>. So it's permissible for us
to have <sys/cdrom.h> point to <io/cam/cdrom.h>. I'd prefer not to,
however, as that means that the SCSI drivers would be including CDFS
include files which they don't really care about and puts them at risk.
>[These issues should have been resolved already for a project that has
>filed (and been granted) an exception request.]
Yep, it was a mis-call on my part as to whether the existence of
<sys/cdrom.h> would cause problems for <io/cam/cdrom.h>.
So, how to proceed? (a) Go with ./kernel/sys/cdrom.h? (b) merge
./kernel/sys/cdrom.h into ./kernel/io/cam/cdrom.h and set up SYMLINK
directives in the appropriate Makefiles (which I believe I understand
how to do; there are examples in ./usr/include/sys/Makefile such as
<sys/dir.h>)?
John
|