On 27 August 2013 15:58, Martin Pieuchot wrote:
> In order to define a proper API for our routine table, I'd like to turn
> the "struct rt_addrinfo" into a private type (ie: only used in route.c
> and rtsock.c).
>
> This type is used by a lost of code in our network stack to add or delete
> a rout
On Tue, Aug 27, 2013 at 03:38:49PM +0200, Martin Pieuchot wrote:
> So I started to play with the routine table and I'm slowly trying to
> unify the various code paths to add and delete route entries. The
> diff below is a first step, it splits rtinit() into rt_add() and
> rt_delete() there should
On Tue, Aug 27, 2013 at 01:54:34PM +0200, Mike Belopuhov wrote:
> On 27 August 2013 13:39, Martin Pieuchot wrote:
> > I think that's the right approach but the current code generating
> > interfaces indexes is too clever from my point of view, it tries
> > to reuse the last index if possible. Thi
On Tue, Aug 27, 2013 at 03:58:51PM +0200, Martin Pieuchot wrote:
> In order to define a proper API for our routine table, I'd like to turn
> the "struct rt_addrinfo" into a private type (ie: only used in route.c
> and rtsock.c).
>
> This type is used by a lost of code in our network stack to add o
In order to define a proper API for our routine table, I'd like to turn
the "struct rt_addrinfo" into a private type (ie: only used in route.c
and rtsock.c).
This type is used by a lost of code in our network stack to add or delete
a route but also in the various *rtrequest() functions. However i
So I started to play with the routine table and I'm slowly trying to
unify the various code paths to add and delete route entries. The
diff below is a first step, it splits rtinit() into rt_add() and
rt_delete() there should be no functional change.
ok?
Index: net/if.c
=
On 27 August 2013 13:39, Martin Pieuchot wrote:
> I think that's the right approach but the current code generating
> interfaces indexes is too clever from my point of view, it tries
> to reuse the last index if possible. This could lead to some
> funny races if we detach and reattach an interfac
On 26/08/13(Mon) 13:36, Mike Belopuhov wrote:
> hi,
>
> in order to make our life a bit easier and prevent rogue
> accesses to the routing table from the hardware interrupt
> context violating all kinds of spl assumptions we would
> like if_link_state_change that is called by network device
> driv
On Tue, Aug 27, 2013 at 10:37:30AM +0200, Martin Pieuchot wrote:
> On 22/08/13(Thu) 23:31, Claudio Jeker wrote:
> > On Wed, Aug 21, 2013 at 09:59:56AM -0700, Loganaden Velvindron wrote:
> > > I'm not sure if applies to OpenBSD as well, but NetBSD
> > > also disallowed SIOCSIFDSTADDR for ioctl.
> >
On 22/08/13(Thu) 23:31, Claudio Jeker wrote:
> On Wed, Aug 21, 2013 at 09:59:56AM -0700, Loganaden Velvindron wrote:
> > I'm not sure if applies to OpenBSD as well, but NetBSD
> > also disallowed SIOCSIFDSTADDR for ioctl.
> > [...]
> >
> > Index: sys/netinet6/in6.c
> >
Hi tech@,
On an ATI Radeon HD 7870 display card with 6 mini-display-ports, I have
plugged screens on the first 3 DP (identified DP1 - DP2 - DP3 on the
bracket).
In Xorg.0.log, the connected output are listed as :
[14.513] (II) RADEON(0): Output DisplayPort-0 connected
[14.513] (II) RADEO
11 matches
Mail list logo