You may want to port your drivers to a STREAMS environment that is not as flexible as LiS (no source) and which also has a different message numbering scheme. In that case you will need to use dynamic conversion. If you set it up at this point you will have an easy time of it when the next case arises.
-- Dave
At 01:14 PM 10/20/2003 Monday, Eugene LiS User wrote:
The other option to address this would be adding yet another question to initial make run, asking to chose db_type compatibility mode(Sun, HPUX, OSF1 ...).
The numbering proposed by Brian looks good, but still does not solve my problem of communication with comm card whose firmware was compiled for being HPUX compatible. No one is going recompile it for LiS compatibility, so I have to do this on host side. Dynamic conversion is not the best option to do this IMHO. I like static better.
-- Eugene
David Grothe <[EMAIL PROTECTED]> wrote:
>If I target LiS-2.17 as the version that has the dev_t changes, which would
>require recompilation of drivers, then that would be a good time to
>incorporate message renumbering as well.
>
>Your message numbering looks fine to me. Do I have permission to use your
>enum in LiS without making LiS a derivative work of LfS and therefore full GPL?
>
>-- Dave
>
>At 04:57 PM 10/17/2003 Friday, Brian F. G. Bidulock wrote:
>>Dave,
>>
>>That would be fine but there is another problem with LiS message
>>type values: QPCTL == M_COPYIN
>>
>>Normally the relation:
>>
>> mp->b_datap->db_type > QPCTL
>>
>>is used to determine if the message is a priority message. This
>>assignment of QPCTL makes it necessary to test as follows:
>>
>> mp->b_datap->db_type >= QPCTL
>>
>>Which is, of course, not SVR 4, and not obvious.
>>
>>Also, the QPCTL message numbering is packed to the QNORM message
>>numbering, meaning that a normal message (e.g. M_EVENT, M_TRAIL) cannot
>>be added or used by a module or driver without renumbering the QPCTL.
>>SVR 4 sets QPCTL to 0x80 and starts numbering QPCTL messages from 0x81
>>up. This leaves plenty of room for private messages between the QNORM
>>range and the QCTL range.
>>
>>To correct this would require bumping all of the priority message type
>>values, meaning they might as well be re-numbered for maximum
>>compatibility. Here is what I have for LfS:
>>
>>(The OSF/1.2 numbering looks like real boo-boo. The OSF values for
>>the QNORM messages, if interpreted in octal instead of hex, would be
>>identical to the other numbering!)
>>
>>/*
>> * Message type compatibility:
>> * S - Solaris
>> * U - UnixWare
>> * O - OSF/1.2
>> * M - Mac OT(AIX)
>> * L - LiS
>> */
>>enum {
>> QNORM = 0x00, /* S U O M L */
>> M_DATA = 0x00, /* S U O M L */
>> M_PROTO = 0x01, /* S U O M L */
>> M_BREAK = 0x08, /* S U O(0x10) M L(0x02) */
>> M_PASSFP = 0x09, /* S U O(0x11) M L(0x06) */
>> M_EVENT = 0x0a, /* S */
>> M_SIG = 0x0b, /* S U O(0x13) M L(0x09) */
>> M_DELAY = 0x0c, /* S U O(0x14) M L(0x04) */
>> M_CTL = 0x0d, /* S U O(0x15) M L(0x03) */
>> M_IOCTL = 0x0e, /* S U O(0x16) M L(0x05) */
>> M_SETOPTS = 0x10, /* S U O(0x20) M L(0x08) */
>> M_RSE = 0x11, /* S U O(0x21) M L(0x07) */
>> M_TRAIL = 0x12, /* U */
>> QPCTL = 0x80, /* S U O M L(0x0a) */
>> M_IOCACK = 0x81, /* S U O M L(0x0a) */
>> M_IOCNAK = 0x82, /* S U O M L(0x0b) */
>> M_PCPROTO = 0x83, /* S U O M L(0x0d) */
>> M_PCSIG = 0x84, /* S U O M L(0x0f) */
>> M_READ = 0x85, /* S U M(0x8b) O(0x8b) L(0x10) */
>> M_FLUSH = 0x86, /* S U O M */
>> M_STOP = 0x87, /* S U O M L(0x11) */
>> M_START = 0x88, /* S U O M L(0x12) */
>> M_HANGUP = 0x89, /* S U O M */
>> M_ERROR = 0x8a, /* S U O M */
>> M_COPYIN = 0x8b, /* S U O(0x8d) M(0x8c) */
>> M_COPYOUT = 0x8c, /* S U O(0x8e) M(0x8d) */
>> M_IOCDATA = 0x8d, /* S U O(0x8f) M(0x8e) L(0x0c) */
>> M_PCRSE = 0x8e, /* S U O(0x90) M(0x90) L(0x0e) */
>> M_STOPI = 0x8f, /* S U O(0x91) M(0x91) L(0x14) */
>> M_STARTI = 0x90, /* S U O(0x92) M(0x92) L(0x13) */
>> /* the rest of these are all over the board, only M_UNHANGUP is
>> common, they have been
>> renumbered so that at least they don't overlap */
>> M_PCCTL = 0x91, /* U */
>> M_PCSETOPTS = 0x92, /* U */
>> M_PCEVENT = 0x93, /* S(0x91) */
>> M_UNHANGUP = 0x94, /* S(0x92) O */
>> M_NOTIFY = 0x95, /* O(0x93) */
>> M_HPDATA = 0x96, /* M(0x93) */
>>};
>>
>>Have you started a 2.17 branch that we can start making these corrections?
>>
>>Unfortunately, because of this (and a few other structural
>>incompatibilities) I've had to largely scrap LiS binary compatibility
>>for LfS in favor of SVR 4 compatibility and have to drop back to source
>>level compatibility for LiS only.
>>
>>--brian
>>
>>
>>On Thu, 16 Oct 2003, Dave Grothe wrote:
>>
>> >
>> > Actually, I just inherited these values from the original author of
>> > LiS. Nobody every made any effort to make them the same as other
>> > STREAMS implementations. Obviously if you are not exporting the
>> > messages the values are arbitrary.
>> > You can certainly redefine them for your own purposes. It would not
>> > be a good idea to change them in the standard LiS since it would break
>> > all existing drivers.
>> > You could also make a translation table that you use in your message
>> > import/export module to do something like:
>> > mp->b_datap->db_type = lis_to_hp[mp->b_datap->db_type] ;
>> > going one direction and:
>> > mp->b_datap->db_type = hp_to_lis[mp->b_datap->db_type] ;
>> > going the other.
>> > -- Dave
>> > At 02:24 PM 10/16/2003 Thursday, Eugene LiS User wrote:
>> >
>> > Hi,
>> > This question is for Dave.
>> > The values of M_IOCTL, M_FLUSH and other message type codes
>> > as they defined in LiS are different from what we see
>> > on Solaris and HPUX(both have the same codes values).
>> > What was the reason for that change?
>> > That change causes the following problem.
>> > The firmware running on my comm card used to run on
>> > Solaris and HPUX boxes without recompilation and it understood
>> > streams message codes sent from the host perfectly.
>> > Now, when the host driver that is compiled and run under LiS
>> > sends down the M_FLUSH, the card firmware does not understand it,
>> > because on Solaris/HPUX M_FLUSH is 0x86, on LiS it is 0x0d.
>> > What would be a good and proper way to resolve this?
>> > Can I just replace codes in LiS strmsg.h files with the ones
>> > from Solaris?
>> > I would greatly appreciate your comments.
>> > --
>> > Eugene
>> > __________________________________________________________________
>> > McAfee VirusScan Online from the Netscape Network.
>> > Comprehensive protection for your entire computer. Get your free
>> > trial today!
>> > [1]http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo
>> > =393397
>> > Get AOL Instant Messenger 5.1 free of charge. Download Now!
>> > [2]http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>> > _______________________________________________
>> > Linux-streams mailing list
>> > [EMAIL PROTECTED]
>> > [3]http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
>> >
>> > References
>> >
>> > 1.
>> http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
>> > 2. http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
>> > 3. http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
>>
>>--
>>Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
>>[EMAIL PROTECTED] ¦ world; the unreasonable one persists in ¦
>>http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
>> ¦ Therefore all progress depends on the ¦
>> ¦ unreasonable man. -- George Bernard Shaw ¦
>
>
__________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397
Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
