"Antonio Huete Jimenez" <tuxillo@quantumachine.net> wrote in message 
news:486bf4f3$0$850$415eb37d@crater_reader.dragonflybsd.org...
> Hi
>
> Here's a working patch for upgrading libevent. It compiles just fine and 
> I'm currently using in one of my DFBSD machines.
>
> http://leaf.dragonflybsd.org/~tuxillo/patches/libevent145.diff
>
> Bug fixes can be found in:
>
> http://levent.svn.sourceforge.net/viewvc/levent/branches/patches-1.4/libevent/ChangeLog?revision=885&view=markup
>
> I don't have the oportunity of checking with bluetooth because I don't 
> have any device, so if someone has devices and time, please check.
>
> Joerg,
> About ABI changes, there are some functions that have been removed, and 
> some parameters slightly changed:
>

..

Considering the primary rationale for importing libevent (to my knowledge) 
is to
support libbluetooth, and given that it is readily available via pkgsrc and 
is
known to have an unstable ABI. Wouldn't it make the most sense (short of
rewriting libbluetooth not to use libevent) to either move libevent into a
subdirectory of libbluetooth and link it directly into libbluetooth, 
potentially
dropping the manpages. Or, expose it as dflibevent or similar noting 
prominently
that it is generally intended for base system use and third party binary
applications should not expect it to maintain a stable ABI? My preference 
would
be toward the former more than the latter, at least until some other 
consumer of
libevent hits base. Either way it would pretty much eliminate any ABI 
breakage
concerns which fly in the face of a preference to upgrade the library upon 
every
new release. I would think the ideal would be for third party applications 
to
prefer pkgsrc for something like this. ABI breakage is probably no big deal 
at
current but could get bumpy down the road (I'm not sure how this would 
factor
into process checkpointing in the case of restoring a libevent-dependant 
process
elsewhere, where libevent exposes a different binary interface). In any 
case,
maintenance and updates of select and poll support for libevent can likely 
be
pulled from the tree.

I can prepare a patch if there is some kind of consensus.

Sam

Hi

Here's a working patch for upgrading libevent. It compiles just fine and 
I'm currently using in one of my DFBSD machines.

http://leaf.dragonflybsd.org/~tuxillo/patches/libevent145.diff

Bug fixes can be found in:

http://levent.svn.sourceforge.net/viewvc/levent/branches/patches-1.4/libevent/ChangeLog?revision=885&view=markup

I don't have the oportunity of checking with bluetooth because I don't 
have any device, so if someone has devices and time, please check.

Joerg,
About ABI changes, there are some functions that have been removed, and 
some parameters slightly changed:

evdns.h
-----------------------------
x Removed function -int evdns_resolv_conf_parse(int flags, const char *);
x Change in function
         -int evdns_server_request_add_reply(struct evdns_server_request 
*req, int section, const char *name, int type, int class, int ttl, int 
datalen, int is_name, const char *data);
         +int evdns_server_request_add_reply(struct evdns_server_request 
*req, int section, const char *name, int type, int dns_class, int ttl, 
int datalen, int is_name, const char *data);

event-internal.h
--------------------
x Deleted RB_HEAD(event_tree, event) timetree;

event.h
--------------------
x Deleted check and structure if not defined:
         #ifndef RB_ENTRY
         #define _EVENT_DEFINED_RBENTRY
         #define RB_ENTRY(type) 
         \
         struct { 
         \
                struct type *rbe_left;          /* left element */ 
         \
                struct type *rbe_right;         /* right element */ 
         \
                struct type *rbe_parent;        /* parent element */ 
         \
                int rbe_color;                  /* node color */ 
         \
         }
         #endif /* !RB_ENTRY */

x In event structure deleted RB_ENTRY (event) ev_timeout_node;
x Deleted void *event_init(void); and replaced with struct event_base 
*event_init(void);
x Replacement:
         int bufferevent_write(struct bufferevent *bufev, void *data, 
size_t size);
         int bufferevent_write(struct bufferevent *bufev, const void 
*data, size_t size);

x Parameter change:
         void evtag_marshal(struct evbuffer *evbuf, uint8_t tag, const 
void *data, uint32_t len);
         void evtag_marshal(struct evbuffer *evbuf, ev_uint32_t tag, 
const void *data, ev_uint32_t len);

         void encode_int(struct evbuffer *evbuf, uint32_t number);
         void encode_int(struct evbuffer *evbuf, ev_uint32_t number);

         void evtag_marshal_int(struct evbuffer *evbuf, uint8_t tag, 
uint32_t integer);
         void evtag_marshal_int(struct evbuffer *evbuf, ev_uint32_t tag, 
ev_uint32_t integer);

         void evtag_marshal_string(struct evbuffer *buf, uint8_t tag, 
const char *string);
         void evtag_marshal_string(struct evbuffer *buf, ev_uint32_t 
tag, const char *string);

         void evtag_marshal_timeval(struct evbuffer *evbuf, uint8_t tag, 
struct timeval *tv);
         void evtag_marshal_timeval(struct evbuffer *evbuf, ev_uint32_t 
tag, struct timeval *tv);

         int evtag_unmarshal(struct evbuffer *src, uint8_t *ptag, struct 
evbuffer *dst);
         int evtag_unmarshal(struct evbuffer *src, ev_uint32_t *ptag, 
struct evbuffer *dst);

         int evtag_peek(struct evbuffer *evbuf, uint8_t *ptag);
         int evtag_peek(struct evbuffer *evbuf, ev_uint32_t *ptag);

         int evtag_peek_length(struct evbuffer *evbuf, uint32_t *plength);
         int evtag_peek_length(struct evbuffer *evbuf, ev_uint32_t 
*plength);

I'll be missing something, for sure, but basically this is what I have 
been able to see.

Samuel Greear (sjg), I invite you to give your opinion here just like at 
IRC ;-)