Artem Kachitchkine wrote:
>> There is one wrinkle however. I may need to access the associated buf
>> (bp) for a packet instead of passing it off for DMA. This is necessary
>> if the HBA has to fall back to PIO, or if the driver needs to "fake" a
>> SCSI transaction. The wrinkle here is that
> There is one wrinkle however. I may need to access the associated buf
> (bp) for a packet instead of passing it off for DMA. This is necessary
> if the HBA has to fall back to PIO, or if the driver needs to "fake" a
> SCSI transaction. The wrinkle here is that none of the entry points
> d
So,
Looking at the SCSA code, it looks like there is a "new" API for DMA and
packet initialization. In particular, scsi_tran_setup_pkt(), when used
with the kmem_cache, also does the work to do the DMA initialization,
binding, etc. that HBA drivers are normally burdened with. (This
appears
> You can add section numbers (separated by commas) in the MANPATH
> variable. These are searched before the sections specified in man.cf.
Though if you use them you may end up tripping over bugs like 6483933:
$ MANPATH=/usr/man:/usr/dt/man
$ time dtsearchpath > /dev/null
real0m0.0
Peter Memishian writes:
> > You can add section numbers (separated by commas) in the MANPATH
> > variable. These are searched before the sections specified in man.cf.
>
> Though if you use them you may end up tripping over bugs like 6483933:
Ouch.
--
James Carlson, Solaris Networking
Richard L. Hamilton writes:
> I don't find any reference in the man source to MANEXT; perhaps
> you mean the MANSECTS setting in a man.cf file? AFAIK, there's no
> comparable environment variable; I wish there were, it would allow
You can add section numbers (separated by commas) in the MANPATH
v
[...]
> >That's pretty much what I did for my own version of
> this;
> >all the pathnames of commands that I knew had man
> pages in
> >/usr/[share]/man ( /usr/bin, /sbin, /usr/sbin,
> /usr/ucb) were
> >mapped to /usr/share/man; all others used a derived
> name
> >(with share/man tried first, then
[...]
>
> Not that /usr/ucb in $PATH is something you should
> do. (Hm, let's
> merge the two ps'es and the whole /usr/ucb thing
> becomes mostly moot
> anyway.
I would suppose that all the stuff that's only in /usr/ucb ought
to be in /usr/bin anyway, with symlinks in /usr/ucb for anyone
that h
