Re: 4.2 patchset for PR#5563/#5704

[n0g0013]

joel,


thanks for the comments.  was looking for help when sent the initial
email.

On 30.01-02:45, Joel Sing wrote:
[ ... ]
 1. Both of these PRs have already been resolved and closed - fix committed in 
 r1.70 of sys/dev/ic/elink3.c (see 
 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/elink3.c). Help is 
 always welcome, however fixing a closed bug is kinda pointless :)

never fixed it; just wanted a patch against 4.2 without having to use
current.  that's what the patchset is for.  i also changed current to
macros because it seemed wrong/bad.

[ ... ]
 2. Patches and technical issues are normally directed to tech@ (assuming it's 
 a diff for an unresolved issue). You'll probably get more of a response than 
 on [EMAIL PROTECTED]

thanks for the pointer.

[ ... ]
 3. Patches are usually provided in a unified diff format (-u option). These 
 are inherently easier to read, especially when sent via email.

thanks again.

[ ... ]
 4. Patches should be provided against -current, not -stable. If a diff is 
 accepted for a serious issue it will be back ported and a patch made 
 available for -stable.

that's what i needed and did.  wasn't sure whether there was
somewhere to post a patchset against stable so others could use it.
is that generally done by others (i.e. unwanted) or posted
elsewhere?

[ ... ]
 5. If you really want to diff against -stable you can use the -rOPENBSD_4_2 
 tag when running cvs. eg:

aside from the '-u' that's what i did.

thanks again for the pointers, much appreciated.

-- 
t
 t
 w

Re: 4.2 patchset for PR#5563/#5704

[ttw+bsd]

On 17.01-22:14, [EMAIL PROTECTED] wrote:
 need an education here.  created a patchset for this problem and i'm
 about to test that against 4.2 GENERIC and have a couple of questions
 
   1.  are the results generally intersting? should i post
   them somewhere (assuming tests go right)
 
 assuming above is yes
 
   2.  had to manually add the line from r1.94 to 'mbuf.h' to skip the
   other changes in r1.93.  is there a cvs way to do that or
   should it be manual and i assume there's nothing for me relevant to
   branching etc as that is only relevant to the repository/commiter,
   right?
 
   3.  m_gethdr duplicates the new m_inithdr code which seems
   ... not great ... would it be better to (a) call the m_inithdr
   function from m_gethdr (b) change it to a macro (c) change
   the m_inithdr to inline and call it from m_gethdr (no idea
   whether the function would get inlined anyway).

i guess the answer to '1' in no but i'm posting this for anyone who
may find it useful.  it's working nicely for me.

comments welcome.

nb: this should patch against 4.2
Index: sys/sys/mbuf.h
===
RCS file: /cvs/src/sys/sys/mbuf.h,v
retrieving revision 1.92
diff -r1.92 mbuf.h
220a221,254
  * mbuf initialisation macros:
  *
  *MINITDATA(struct mbuf *m, int type, u_short flags, caddr_t data)
  * initialize mbuf internal data (pulled in by MINIT and MINITHDR)
  *
  *MINIT(struct mbuf *m, int type)
  * initialize an mbuf
  *
  *MINITHDR(struct mbuf *m, int type)
  * initialize mbuf with packet header
  */
 #define MINITDATA(m, type, flags, data) \
   (m)-m_type = (type); \
   (m)-m_flags = (flags); \
   (m)-m_data = (data); \
   (m)-m_next = (struct mbuf *)NULL; \
   (m)-m_nextpkt = (struct mbuf *)NULL
 
 #define MINIT(m, type) \
   MINITDATA((m), (type), 0, (m)-m_dat);
 
 #define MINITHDR(m, type) \
   MINITDATA((m), (type), M_PKTHDR, (m)-m_pktdat); \
   (m)-m_pkthdr.rcvif = NULL; \
   SLIST_INIT((m)-m_pkthdr.tags); \
   (m)-m_pkthdr.csum_flags = 0; \
   (m)-m_pkthdr.pf.hdr = NULL; \
   (m)-m_pkthdr.pf.rtableid = 0; \
   (m)-m_pkthdr.pf.qid = 0; \
   (m)-m_pkthdr.pf.tag = 0; \
   (m)-m_pkthdr.pf.flags = 0; \
   (m)-m_pkthdr.pf.routed = 0
 
 /*
Index: sys/kern/uipc_mbuf.c
===
RCS file: /cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.85
diff -r1.85 uipc_mbuf.c
167d166
   m-m_type = type;
169,172c168
   m-m_next = (struct mbuf *)NULL;
   m-m_nextpkt = (struct mbuf *)NULL;
   m-m_data = m-m_dat;
   m-m_flags = 0;
---
   MINIT(m, type);
187d182
   m-m_type = type;
189,201c184
   m-m_next = (struct mbuf *)NULL;
   m-m_nextpkt = (struct mbuf *)NULL;
   m-m_data = m-m_pktdat;
   m-m_flags = M_PKTHDR;
   m-m_pkthdr.rcvif = NULL;
   SLIST_INIT(m-m_pkthdr.tags);
   m-m_pkthdr.csum_flags = 0;
   m-m_pkthdr.pf.hdr = NULL;
   m-m_pkthdr.pf.rtableid = 0;
   m-m_pkthdr.pf.qid = 0;
   m-m_pkthdr.pf.tag = 0;
   m-m_pkthdr.pf.flags = 0;
   m-m_pkthdr.pf.routed = 0;
---
   MINITHDR(m, type);
Index: sys/dev/ic/elink3.c
===
RCS file: /cvs/src/sys/dev/ic/elink3.c,v
retrieving revision 1.69
diff -r1.69 elink3.c
1390c1390
   /* Convert one of our saved mbuf's. */
---
   /* Convert one of our saved mbuf's ... */
1392,1395c1392,1393
   m-m_data = m-m_pktdat;
   m-m_flags = M_PKTHDR;
   m_tag_init(m);
   m-m_pkthdr.csum_flags = 0;
---
   /* ... and reset the buffer info */
   MINITHDR(m, m-m_type);

4.2 patchset for PR#5563

[ttw+bsd]

need an education here.  created a patchset for this problem and i'm
about to test that against 4.2 GENERIC and have a couple of questions

1.  are the results generally intersting? should i post
them somewhere (assuming tests go right)

assuming above is yes

2.  had to manually add the line from r1.94 to 'mbuf.h' to skip the
other changes in r1.93.  is there a cvs way to do that or
should it be manual and i assume there's nothing for me relevant to
branching etc as that is only relevant to the repository/commiter,
right?

3.  m_gethdr duplicates the new m_inithdr code which seems
... not great ... would it be better to (a) call the m_inithdr
function from m_gethdr (b) change it to a macro (c) change
the m_inithdr to inline and call it from m_gethdr (no idea
whether the function would get inlined anyway).

and finally, how do i create a patchset?  is it simply a concat of
the individual file patches?