in any case, as john said, having control commands in the command stream is
a perfectly good way to do it. Defining bunch of more registers and bloating
the core transport sounds like a bad design, not the other way around.
we do allow passthrough to a device and the lower sbp2 driver can whack the
device directly using our 1394 api. However we dont expose that device
specific functionality up to our class driver. They dont need to know hacky
methods of configuring the device.
We layer:
command set class driver
Transports
Bus specific drivers
hw specific drivers
thanx
g
> -----Original Message-----
> From: Eric Anderson [SMTP:ewa@apple.com]
> Sent: Monday, July 13, 1998 6:40 PM
> To: p1394@pwg.org
> Cc: George Chrysanthakopoulos; John Nels Fuller; Greg Shue
> Subject: Re: P1394> Ways to do parameter setup
>
> Since I have not been participating, I want to be careful not to
> criticize. But I agree with Greg - it seems like good SBP-2
> services should not get in the way of natural communication with
> a device. It sounds like Windows' services make some assumptions
> or simplifications that may be too limiting.
>
> In Mac OS, the SBP-2 services are merged with the basic 1394
> services. SBP-2 is not a separate layer that hides 1394; instead
> SBP-2 services are available alongside basic 1394 services. So a
> driver can use efficient SBP-2 transfers, while still directly
> accessing a device through 1394 (if it wants to). Maybe this is
> also true in Windows, but from the restrictions John mentioned,
> it sounds like there may be room for improvement.
>
> It would be a shame to define awkward or inefficient peripheral
> protocols just because of software limitataions in an OS. Software
> can always be fixed, while poor protocols seem to have long lives.
>
> --------------------------------------
> Eric Anderson ewa@apple.com
> Apple Computer, Inc. 408-974-8187
> --------------------------------------
>
> >> Hi everyone,
> >>
> >> I talked to George C. about the three possible ways we were considering
> for
> >> setting connection parameters:
> >>
> >> 1. Using command-set dependant management commands. There is no way
> >> for the class driver to cause the SBP-2 driver to send these, so I
> guess
> >> they are out.
> >
> >Too bad.
> >
> >> 2. Using additional registers in the command agent register block.
> >> There is no way for the class driver to discover these addresses or to
> >> deliver requests directly to the 1394 bus driver, so again no luck.
> >
> >Oh well.
> >
> >> 3. Using commands in the normal command stream. This will work (as we
> >> knew in Monterey), so we'll have to figure out a way to ensure that the
> in
> >> and out queues are both idle when they are issued (but we really needed
> to
> >> do that for 1 & 2 as well).
> >
> >Any progress on getting the Device Type to be dependent on Command_Set?
> >
> >
> >--
> >Greg Shue
> >Hewlett-Packard Company
> >All-in-One Division gregs@sdd.hp.com
> >----------------------------------------------------------------
>
>
>