Re: [Pengfork-devel] Work state

[Nicolas Burrus]

On Monday 26 August 2002 00:02, Jean-Charles Salzeber wrote:
> On Sun, Aug 25, 2002 at 22:29, Nicolas Burrus wrote:
> > On Saturday 24 August 2002 16:38, Jean-Charles Salzeber wrote:
> > > Just for information are
> > >
> > > cat </dev/net/tun
> >
> > # cat </dev/net/tun
> > cat: -: File descriptor in bad state
> >
> > > ifconfig tun0 10.0.0.1 10.0.0.2 up
> >
> > # ifconfig tun0 10.0.0.1 10.0.0.2 up
> > SIOCSIFADDR: No such device
> > tun0: ERROR while getting interface flags: No such device
>
> Grrr... you've got the same error as me! ;)
>
> AFAIK this commands should work. Your tun device isn't working, as me.
> If you try running vtun it will not work, as all program using the tun
> device.
>
> I've investigated the problem, currently no good answer to say what
> happens. I've looked at the vtun mailing-list for similar problems,
> but never see a good reply that suit my configuration.
> What kernel version do you use?
> As far as I remember my tun device were working some month?/years? ago.

I think I am in the same situation than you, It has been working one day as I 
used pengaol with tuntap driver, but now it doesn't seem to work. I use a 
2.419 kernel patched by gentoo, but I don't think they have changed anything 
in the tuntap driver.

> Help to solve this problem is very welcome since I'm locked on Linux.
> I will develop on OpenBSD until I find the solution.

Ok, I'll try to investigate too.

> > Just a little remark, prot30_send_packet in prot30.c seems to call
> > buffer_alloc quite late, and I don't understand why buffer_alloc does not
> > extend the buffer if necessary.
>
> Humm... you 're right, the name buffer_alloc isn't a suitable name. The
> memory isn't allocated. This just modify the 'used' field on the buffer.
> buffer_alloc can be done every where in the function after the
> buffer_end.

Ok, that's what I deduced, but in this case, in the function, when you do 
place your header and data pointer at buffer_end(), how are you sure you will 
have enough pre-allocated space ?

> > Will the code be imported in CVS soon ?
>
> Don't know. I'm a bit disapointed because my work has been slowed down
> with a stupid problem for now few days.
> It can be imported at any time, if you wish to help me and agreed with
> the global design.
> Before doing this we have to find a better directory structure and
> perhaps start to hack an autoconf/automake file.

Ok, in fact I was waiting for cvs import to add auto* stuff :) It won't change 
anything to the project structure.

> Currently my directory structure is:
> pengfork
>   + include

I don't really like a separated include dir (for editing and searching 
reasons), but it is totally personnal, so if you like it, it's ok with me.

>   + src
>       + linux
>       + openbsd
>       + freebsd

Hum, do you really need one directory by architecture ?

> But if we plan to make a 'pengctl',a gui program where will we put them?
> as separate modules?

I see 2 choices :

1) Include them in pengfork hierarchy this way :
  + pengfork/
     + src/ ==> pengfork core src
     + pengctl/
        + src/
     + pengui/
        + src/

This way we consider pengfork as the main binary, and pengctl and pengui as 
sattelite programs.

2) Make them separated projects
  I like modularizing projects :) The 3 parts does not seem to need sharing 
source code, so why not creating 3 separated entities, with maybe a tarball 
which contains the 3 parts when doing a release ?

I prefer solution 2), which create more separated modules, does not oblige the 
user to download the 3 parts, does not highlight one particular GUI among 
others (there may be several guis by different people one day :). It also 
permits multiple extensions without making the main project heavier.

-- 
Nicolas