[00:06] hmm matt, you said you would test O(1) ctx ? [00:23] well, if it will work with your rmap/ml patches also, yes [00:23] no, we won't test everything at once ... [00:24] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [00:27] @matt of course you are free to test whatever you want, but if it should make any sense, you should test the O(1)+ctx or even better the O(1) without ctx ... [00:29] ohhh [00:29] what's there to test then? [00:29] i don't understand how to test something like that [00:30] well, _if_ you want to test O(1) + ctx then probably the behaviour of different servers and their services will be somewhat unusual .. as the scheduler is not really tuned yet ... [00:30] typical tests would be starvation and processes running wild ... [00:32] for example running some heavy math or other cpu task in one server, and see how responsiveness is in another server ... [00:40] http://vserver.13thfloor.at/Experimental/patch-2.4.23-pre7-O1c17f.diff.bz2 [00:40] this is the O(1) scheduler + c17f in one patch ... [00:40] compiled and tested, result: doesn't explode immediately ;) [01:03] okay, anything new? any questions? [02:05] because the RSS isn't enforced either ... [02:16] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [02:23] Bertl (~herbert@MAIL.13thfloor.at) left irc: Remote host closed the connection [02:28] Bertl (~herbert@212.16.62.51) joined #vserver. [02:28] did I miss something? [02:30] nope [02:34] JonB (~jon@kg184.kollegiegaarden.dk) left irc: Quit: zzzzz [02:44] hmm and the fake_stat is wrong too :( [02:48] hrm [02:48] booted the kernel and it worked [02:48] then I just added tagctx to fstab and now it's not coming up... [02:48] gotta wait to find out what's on the consoler [02:49] that is a problem, as now when the stock kernel boots it won't recognize that mount option and the boot will fail [02:49] i am now not in favor of a mount option :) [02:50] hmm, you insist on using the rootfs for that? [02:51] i'm using /home [02:51] but it will still fail [02:51] huh, and this gives troubles with tagctx? [02:51] i'm only assuming that is it, it's the only thing that changed... [02:51] which kernel is it now? (I mean patches?) [02:51] Bertl: i'm saying, if you try to boot a non-tagctx aware kernel the boot will fail [02:52] hmm, never tried ... give me a few seconds ... [02:53] yup, fails ... correct [02:55] what was the other method you proposed ? [02:55] serving- (~serving@213.186.189.26) left irc: Ping timeout: 492 seconds [02:56] hmm, besides using the tagctx flag? [02:56] yes [02:56] don't remember anymore ... [02:56] heh [03:08] hmm, you had some issues with page/1k conversion, where was this? [03:29] hey just compiling patch-2.4.23-pre7-O1c17f.diff kernel [03:30] if any testing needed show me how and ill do it [03:30] wow, cool ... [03:31] wi -03 and -pipe added and the stack boundarie option in kernel hacking [03:31] well basically you could try to start some cpu bound app (like something usually using up 100%) and test if some other server still is responsive ... [03:32] -g is also a good option ... [03:32] hey i dont know that one [03:32] it gives you the ability to convert ksymoops addresses to line numbers ;) [03:32] -g is debug, but only add it for the kernel flags ... [03:32] yeas i lack of debugging option [03:33] cause i use fomit-pointer [03:33] in 2.6 this is an option in the kernel hacking ... [04:10] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [04:20] @cmaj and? compiling done? [04:21] cmaj the ASCI asrtist :P [04:21] >= 2 keybord owner ;) [04:22] lol [04:22] is a real frirend of mine [04:22] yeas but when i was at make moodules i remeber my need for netfillter [04:22] i know him since 10 years + [04:22] aahah actually there where 3 keybord on my desk at that time [04:23] so i recompile it with -g and no fomit-frame-pointer [04:23] yeas good friend of mine [04:23] :) [04:23] actually i discover vserver because of him [04:25] hmm, the disk limit stuff actually is a little strange ... [04:31] hmm, looks much better now, since I fixed the bug ;) [04:32] alekibango (~john@b59.brno.mistral.cz) left irc: Quit: Client killed by consultant [04:47] serving (~serving@213.186.190.152) joined #vserver. [05:18] newz (~admin@169-52.34-65.tampabay.rr.com) joined #vserver. [05:18] hi newz! [05:19] Hey. [05:19] Well, ready to see a concept? [05:19] always? [05:19] always! [05:19] OK, I haven't done anything to the logo, so keep in mind it will change radically... [05:19] have you read all the postings? [05:19] http://newz.gotdns.com/vserver-web-concept.png [05:20] Yeah... I've read the postings... I'll take some of the ideas and some I'll have to leave. [05:20] hmm, not bad ... [05:20] There's no way I can do the matrix thing though. :-D [05:21] okay want my comments? [05:21] Yep. [05:21] That's why I"m here [05:22] logo background should be smaller (not so wide) more like the menu below .. [05:22] the back bar with the shadow below the logo is nice ... [05:23] the text in the upper right should be text ... if necessary with custom font ... but text ... [05:23] Yep. [05:24] I'm not sure we ca use the menu space though, but it looks good ... so maybe we can do something useful with it ;) [05:24] isn't the shadow at the bottom totally wrong *G* [05:24] "If you build it, they will come." [05:24] Yeah, I don't like it either, but it needs something... NOt sure what though. [05:25] turn it upward down ... just for a test ... [05:25] I tried, it gives the page too much of a tiered look. [05:25] I'll probably do a 1 pixel gray line above the black line. [05:26] Or maybe a 1 px black line, a 1 pix white line above the black line [05:26] Let me try that real quick... [05:26] what about putting the whole copyright/feature bar into the black bar? [05:26] and have the shadow just below that bar ... [05:27] It gives the effect of putting the text in the footer in BIG BOLD LETTERS [05:27] Really that's the stuff that shouldn't catch the eye. [05:28] if it's moderate grey on black, I don't think this is too much ... [05:29] i ready too reboot but not my users [05:29] hmm, could you make a version with the black bar at 4-6 pixels and have the shadow below like on the top bar ... [05:29] Sure. [05:30] maybe with the menu continuing below that bar ... [05:30] like it is hovering at the bottom ... slightly above the page ... [05:30] @cmaj well, take your users time ;) [05:32] @newz the magnifying glass should definitely reach over the back bar at the top too ... [05:34] http://newz.gotdns.com/vserver-web-concept2.png and http://newz.gotdns.com/vserver-web-concept3.png [05:34] ahh, now I see what irritated me about this logo last time: the image through the magnifying glass isn't enlarged at all ;) [05:35] Yes it is [05:35] It's just that such a small image there's no way to make it extremely obvious [05:35] okay, but it looks like it isn't because of the upper edge ... [05:36] Yeah, that's because the upper edge is closer to the server [05:36] hmm concept2 looks boring ... [05:37] concept3 looks a little strange ... maybe the bar should be 10-12 pixel and/or contain something after all ... [05:37] Well, I think the drop shadow should be closer to the bar. [05:37] hang on a sec... I'll try it. [05:38] hmm, if you do that, it's distance will become smaller ... [05:38] which isn't what you want, unless you change the top bar drop shadow too ... [05:39] Check out 4... I don't think it's distance matters too much, the footer should not have equal weight to the header [05:40] that was too much in any case, it is visible above the bar ;) [05:40] I liked that. [05:40] but you are right, the distance doesn't matter in this case ... [05:42] just for another test, could you move the vertical line between logo and text to the left, until it matches with the menu vertical separator ... just move the logo out of the screen ... [05:42] Let me see... That may be non-trivial [05:43] Before I do that, what do you think of the text I used in the header, especially the tag line? [05:43] forget about the logo and the right side ... [05:43] please explain tag line? [05:43] I just grabbed off the freshmeat project page [05:44] I'm really not qualified to make a tag line from scratch [05:44] hmm, what is a tag line? [05:44] A catchy phrase that describes your product in half a sentance [05:44] Independant servers simultaneously in one box [05:45] ahh okay ... got it [05:45] hmm, well we had a tag line ... [05:45] Do you know what it was? [05:46] vserver: run general purpose virtual servers on one box, full speed! [05:46] Ah... Didn't see that anywhere. Is that what you want in the header? [05:46] hmm, guess we'll ask around a little ... [05:46] ok. [05:47] for my part, I would scratch the 'general purpose' part ... [05:47] I'd also scratch "run" and replace with something like "multiple" [05:47] sounds good ... [05:47] "multiple virtual servers on one box at full speed!" or similar [05:48] I'll create a concept with that if you like, then we can post them to the list [05:49] I guess it would be enough to post the current versions and wait for the responses ... [05:49] ok. Can do. [05:54] http://vserver.13thfloor.at/Stuff/vserver-web-concept4b.png [05:55] that was what I meant with the left shift ... [05:59] ok, let me see if I can do that... Of course, the logo is going to be different, so it may be a moot point by then. [06:00] and I would consider the back bar below the logo to be a part of the logo ... if it makes sense ... [06:00] s/back/black/ [06:00] Yes [06:01] At least the first 2 or 3 pixels [06:01] the whole bar down to 5 pixel distance ... [06:02] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [06:03] Whatever it takes to not chop the image off. ;-) [06:04] well, the w3c icons (those are mine, correct?) should start right of the menu bar ... [06:06] but the overall look and feel is very nice ... [06:06] Cmaj (moi@207.253.236.180) left irc: Quit: lets do it oh [06:06] Yes, I grabbed those from your site. Nice and small [06:07] they are hand drawn ;) [06:07] http://newz.gotdns.com/vserver.php choose option 5 [06:08] nope, the server should definitely stay inside the blue space ... the glass can reach out ... [06:08] Let's decide on a logo before we decide what parts should be in and out of the blue. [06:09] That logo isn't going to be the final product. [06:09] okay, no problem with that ;) [06:09] Unless the consensus changes once they see it in this design. [06:10] please add the 4b version too .. if possible ... [06:10] ok [06:10] and thanks for your time ... [06:10] no prob [06:11] is it intentional that you write 'copywrite' not 'copyright'? [06:12] No, it was "lack of a spell checking in photoshop." :-) [06:13] okay, you are going to post something to the list? [06:13] What has this world come to? Can't write with out a spell checker. :-D [06:13] Yep... I just added the "4b" link and I'll post it now. [06:13] perfect, because I'm going to bed ... [06:14] have to get some sleep after all ... [06:14] night everyone ... [06:14] Night [06:14] Nick change: Bertl -> Bertl_zZ [06:28] newz (~admin@169-52.34-65.tampabay.rr.com) left irc: Quit: Client exiting [06:38] CJDeCKeR (moi@207.253.236.180) joined #vserver. [06:38] Nick change: CJDeCKeR -> Cmaj [06:52] everything looks fine [07:17] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [07:58] mdaur_ (mdaur@p509150AE.dip.t-dialin.net) joined #vserver. [08:04] mdaur__ (mdaur@p509163A6.dip.t-dialin.net) left irc: Ping timeout: 492 seconds [08:44] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Quit: ipv6 [09:09] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) joined #vserver. [10:55] moin [13:14] say-out (~cryostar@212.86.243.154) joined #vserver. [13:55] Nick change: say-out -> say [13:58] gaertner (~gaertnerl@212.68.83.160) left #vserver. [14:37] alekibango (~john@b59.brno.mistral.cz) joined #vserver. [16:00] Nick change: Bertl_zZ -> Bertl [16:00] hi, short visit! [16:00] any urgent issues? O(1)-c17f seems to work? [16:01] Bertl: are there any other codechanges in o(1)-c17f beside kernel/sched.c? [16:02] virtuoso (~shisha@tower.ptc.spbu.ru) joined #vserver. [16:02] not from the ctx side ... [16:02] hi virtuoso! [16:02] Gday. [16:02] Bertl: You're Herbert, right? :) [16:02] right! [16:03] Well.. I thought you might have ctx patch for 2.6-testN. [16:03] :) [16:03] not yet ;) [16:03] but one of the major issues for 2.6 (the scheduler) seems to be solved ;) [16:04] Did you try to port ctx for 2.5 branch? [16:04] so if you want to help, you could test the hell out of that version ... [16:04] nope .. no reason IMHO ... [16:05] but you are welcome to port it ... [16:05] I sure want to help. [16:05] In case of 2.6, of coz. :) [16:06] Action: virtuoso still has some troubles with 2.6 though.. [16:07] Something with this new modutils. [16:08] well they use new config files ... [16:09] Could you please point me to some url about that? [16:09] or better some changed configuration syntax ... but there is a conversion utility ... [16:11] there was some good page on KernelTrap but it is gone now ... [16:11] but you can use the cached version of google ;) [16:11] search for 2.6 modutils conversion [16:11] there should be some Feature: HowTo Upgrade ... [16:13] Uh, I think this one: http://kerneltrap.org/node/view/799 [16:13] ? [16:13] Big thanks. [16:13] you're welcome ... [16:15] okay, will be back in a few hours ... [16:15] Nick change: Bertl -> Bertl_oO [17:27] serving (~serving@213.186.190.152) left irc: Ping timeout: 483 seconds [18:48] say (~cryostar@212.86.243.154) left irc: Read error: Connection reset by peer [19:00] serving (~serving@213.186.191.81) joined #vserver. [19:06] say (~cryostar@212.86.243.154) joined #vserver. [19:16] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) joined #vserver. [19:24] shuri (~ipv6@cpu183.adsl.qc.bellglobal.com) left irc: Read error: No route to host [19:40] Nick change: Bertl_oO -> Bertl [19:40] hi all! [19:41] Morning [19:41] shadow (shadow@di-169.ttn.ru) joined #vserver. [19:42] Hi all [19:47] hi alex, hi nesh! [19:47] Hi Herbert [20:00] @alex,say how is your bugfix going? [20:01] Herbert - i don`t return to workplace. [20:02] hmm, okay maybe you could explain the basic principles of your virtualized network to me? [20:03] okey :) [20:03] great! [20:04] I have your kernel-2.4.18-27.7.x-1065436704 in front of me .. so you can refer me to some files/functions ;) [20:06] i don`t have linux :) but i try explain. [20:06] okay ... [20:08] noel (~noel@80.142.180.170) joined #vserver. [20:09] on real device created pointer to virtual network grouup as in "trunk group" [20:11] after decoding ip header - do scan this network group for find who is virtual network devices owned this packet. [20:12] if it not found - assumed base device. [20:14] in routing tables added one pointer for separate per context. [20:15] i do not full divide routing tables because in this variant we can`t send packet for virtual devices in same host. [20:16] in ip_route_output_slow added small hack for change device for packet (if packet sending to other context) [20:18] in this variant packet transmised to loopback of recipient. [20:20] that small explain... [20:21] hmm .. give me a few minutes ... [20:22] okey. [20:22] have to think it through ... [20:36] hmm, okay may I ask a few questions? [20:36] okey :) [20:37] you check the ip address (header) if it belongs to a virtual server, correct? [20:38] i check it in function ip_rcv and change skb->dev for this packet. [20:38] ah okay, so you 'tag' the packet, correct? [20:39] not. [20:39] in current skb (struct sk_buff) not have tag, but in unstable patches i add it. [20:40] okay, the idea is to 'tag' each received packet as 'belonging' to virtual context .. right? [20:41] and the current version just changes the device ... [20:42] serving (~serving@213.186.191.81) left irc: Ping timeout: 483 seconds [20:42] skb->dev=fixnetdev(skb->nh.iph->daddr,dev); [20:43] yes. it change device for skb packet. [20:43] will this be required in the unstable version? [20:44] by the way, where can one get the 'unstable patches'? [20:45] not :) [20:46] in unstable version at this point added skb->s_context = skb->dev->s_context; [20:46] okay the routing table checks are don where? [20:46] s/don/done/ [20:48] in hash_lockup / fib_lockup function. [20:49] see fib_frontend -> function addr_type as example. [20:49] let's try some what-if scenario, okay? [20:49] okey. [20:50] imagine an unpatched kernel vanilla, or RH (but no ctx patches) [20:50] you know iptables and marking/tagging I presume ... [20:51] rh and vanila have very small changes in network subsystem. [20:51] I could tag/mark each packet on input via some rule, right? [20:52] I could also put it on a separate routing table (max 255 are available IIRC) ... [20:52] not. [20:52] okay, what is the problem? [20:53] for iptables - rules stored as pointer in context structure and for find mached rule be scan only rules created in context who owned skb packet. [20:54] yeah, okay, this probably _is_ faster but for an incoming packet the current (unpatched) kernel should be sufficient, or am I wrong? [20:56] I'm not talking about changing those tables from inside for this scenario .. [20:57] ensc (~ensc@134.109.116.202) joined #vserver. [20:57] yes. it sufficient. [20:57] hi enrico! [20:58] Bertl: hello [20:58] but if you full separate routing tables - you don`t send packet from one context to other.. [20:58] @enrico we have to talk about the syscalls .. in 20 min okay? [20:58] Bertl: yes; I tried to answer your mail from saturday, but my mail was refused by your mailserver [21:04] probably your mailer/mailhost is cofigured badly ... [21:05] @alex okay now for packet leaving a context ... [21:05] they could simply be tagged with the context info, right? [21:05] @enrico your host name? [21:06] in current context info not dircectly stored in skb packet. [21:06] Bertl: I used 'londo.ultra.csn.tu-chemnitz.de' [21:07] Bertl: the mail was coming from a dialup ip, and the hostname is not resolvable [21:07] yeah, okay but the 'marking/tagging' the iptable does [21:07] could be used for throwing the packet in the right table .. [21:08] @enrico Out: 550 : Helo command rejected: Host not [21:08] found [21:08] yes; this was in the bounce also [21:08] when context sending out - in net_tx (i not remember fullname it`s function) device be changed from virtual to host. [21:08] @enrico, you should mail over some mailer, maybe maul.tu-chemnitz.de ... or whatever is apropriate ... [21:09] Bertl: not doable; I am choosing random call-by-call providers and I can not find suitable SMART_HOSTS for them [21:09] okay, no the last question, the creation of the 'virtual' device visible inside the context ... [21:10] s/no/now/ [21:10] you just do it in the namespace of the context? [21:10] not. [21:11] okay, please elaborate ... [21:11] @enrico please have a look at http://vserver.13thfloor.at/Stuff/virtual.[hc] in the meantime [21:12] eache device have pointer to context and in all function who need find device added parametr "context" for select right device [21:13] okay, so you do for example 3 times eth0 if required ... each with a separate context pointer ... [21:14] yes. [21:17] Bertl: is 'struct { uint32_t ip[]; ... mask[]; };' really compilable? [21:27] whell.. i go to sleep. [21:27] bye to all [21:30] bye ... [21:32] okay enrico ... [21:33] hmm, that struct is one thing we have to talk about ;) [21:33] shadow (shadow@di-169.ttn.ru) left irc: Quit: укосолапил [21:33] the current userspace implementation transmits an array of unknown size, or better a size value and two pointers ... [21:34] those contain the possible ip addresses ... [21:34] right? [21:35] yes [21:35] I would like to change this to smewhat more static/predefined ... [21:35] I would transmit an array of 'struct { uint32_t ip, uint32_t mask }' elements [21:35] maybe we can drop the array part completely? [21:36] you mean calling this syscall subsequently for each pair? [21:36] rik suggested doing some range stuff in the future, but this is not an option for the current setup, so yes ... [21:37] maybe we could do something like a 'add ip/mask to slot N' [21:37] ranges? Sounds complicated to implement [21:38] and N can be <= (M+1) where M is the current number of slots [21:38] with a maximum of NB_IP... of course ... [21:38] I would try to omit such static limitations [21:38] hmm, please explain ... [21:39] we are talking about the userspace/kernel interface not the in kernel implementation, which will be the same for the moment ... [21:40] implementing kernel 'struct iproot_info' as { ... __u32 *ipv4; __u32 *mask; ...}' would allow to do '...ipv4 = kmalloc(nb * sizeof(__u32));' [21:40] I do not like static limitations [21:40] I thought you where addressing this ... [21:41] well the issue is the algorithms don't scale well for larger arrays ... [21:41] but what do you think of the userspace/kernel interface? [21:42] ok, but when I want 17 IPs I would have to recompile the kernel [21:42] we don't want to keep the network stuff anyway ... [21:43] todays topic: syscall switch for _current_ c17f ;) [21:43] when using current kernel-code, I would use the all-by-one-call method [21:43] the problem is that we cannot pass the two pointers for the ip/mask anymore ;) [21:44] we could, but I would consider it a bad hack, use the id to pass the nbip, and then calculate the variable struct ... [21:45] why not pass the ip/mask values one by one? [21:46] it doesn't change the userspace ode much, it will not change the kernel behaviour ... and it might be used with variable sized versions too ... [21:46] s/ode/code/ [21:46] ok; I do not have a problem with it [21:46] If you have a better idea, say it ... [21:47] another option would be to pass always the full static 16 ip/mask values ... [21:47] no; passing each pair once-by-once is the best way [21:49] or passing 'struct { __u32 ip; __u32 mask; }' pairs, which can be in a variable sized array at the end of the struct [21:49] so we change the struct to uint32_t ip, uint32_t mask, uint32_t broadcast and use the id to select the slot, what do you think? [21:49] we have to map the entire struct from userspace to kernel space ... it's not good to map it twice ... [21:50] (we would need to know the size in advance ;) [21:50] yes, you are right [21:51] okay, how long will it take to adapt your userspace tools? [21:51] but when calling the syscall for each pair, you would do user->kernelspace mapping multiple times aslo [21:52] should be done in a short time (<1 day I guess) [21:52] okay, next question, how can we make userspace tools working on both versions? [21:53] or should we forget about that kind of compatibility at all? [21:53] perhaps through the get-version call [21:54] good idea ;)# [21:54] but I would drop backward compatibility as soon as possible [21:58] hmm, well how compatible is the current version to older kernel releases? [21:58] does a ctx12 work with your current tools? [21:58] I have never tried ctx12 [21:59] but the tools are supporting all revisions of the syscalls [21:59] how large is the overhead? [21:59] huge [21:59] > 100 lines of code? [21:59] the parsing is implemented with stdio whcih adds 7k of bloat [22:00] forget your perversions for a moment ;) [22:00] :) [22:00] Evening guys. [22:00] why pervesions? Usual binaries are around 5-6k [22:02] the old code can be kept and enable with ./configure switches [22:02] hay my hello worl is 10 bytes in assembler ;) [22:03] Bertl: how that? 'hello world' itself is 11 bytes [22:03] well, the user has to type it in ;) [22:04] okay so we make the code optional by ./configure options ... and have a fallback if the vsersion syscall doesn't return usefull stuff, correct? [22:05] :) interactive hello world [22:05] well as enrico pointed out it saves 12 bytes ;) [22:06] Bertl: yes, but sometime the old /proc-parsing stuff will be dropped [22:06] alekibango (~john@b59.brno.mistral.cz) left irc: Quit: Client killed by consultant [22:06] if you want a clean cut, let us make it now ... [22:07] we'll make a vserver-1.0.0 release soon and if the syscall stuff gets in before, we can drop the compatibility completely ... [22:07] but we need to test user and kernel space on all platforms ... [22:08] the compatibility layer will not be much code [22:08] and I'm not sure that we can make it in reasonable time ... [22:08] so I will use the ./configure switch [22:09] okay ... I'll update the interface struct now ... could you start to adapt the tools, I'll have a kernel side version in a few hours ... maybe we could test both then? [22:10] ok, give me the interface and I will port the tools [22:11] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 492 seconds [22:13] http://vserver.13thfloor.at/Stuff/virtual.h [22:15] Bertl: what is with additional functions? E.g. getctx() or getip4root()? [22:18] or atomic killall/killctx [22:20] Bertl: should 'struct vcmd_set_ipv4root_v3' really have a 'broadcast' member? In current version, it is globally [22:20] ad getctx getip4root: we don't have them yet? correct? [22:21] no [22:21] functionality was emulated by parsing /proc entries [22:21] they will be added as experimental features soon ... [22:21] ad broadcast: I know, just pass it in every struct ... [22:21] we have to make some additional rules ... [22:22] hello. is it still a problem to use 127.0.0.1 in vservers? http://www.paul.sladen.org/vserver/archives/200211/0072.html says its being worked on but I think you know more.:) [22:22] currently you would not be able to reduce the number of entries ... [22:22] I would suggest setting the mentioned M to the last N ... [22:22] dynamic reallocation... [22:22] this way you can reduce to a single entry ... would this be apropriate? [22:23] @noel could you check with c17f if this is still an issue? [22:23] Bertl: ok. will try it on the sparc. [22:24] even better .. this way we have the sparc checked too ;) [22:24] Bertl: this is not an userspace issue, but I do not like dynamic allocations [22:24] could you also test the syscall switch in the next few days? [22:24] @ensc what do you mean by dynamic allocations? [22:25] Bertl: is there a deeper reason for naming it c17f and not ctx17f (sorry if I overlooked the reason). [22:25] setting 'M' to the last 'N' [22:25] @noel yes, to separate it from ctx17 and to save some typing, and last but not least to make the people think ;) [22:26] or do you want to make M yes, exactly .. no changes in the structures for now ... [22:26] ok; it is ugly but working [22:26] I don't want to modify _anything_ except for the value passing ... [22:27] any better suggestions are welcome ;) [22:28] @noel the mangling of local addresses is not implemented ... but different addresses like 127.0.0.2 would be possible, I presume ... [22:29] Bertl: hmm, ok. thx. Will try to get it working with 127.0.0.2 and 127.0.0.3... thx. [22:29] I would use four syscalls: 1. set_ipv4root_count --> allocates memory for the given count of ip/mask pairs; 2. set_ipvroot_ip --> sets a given slot; 3. set_ipv4root_ips --> sets all pairs; 4. set_ipv4root_broadcast [22:32] problems I see: 1. dynamic allocation (new feature, new bugs, NB_IPV4ROOT still used in the code) 2. how to handle successive allocations? 3. what is the default data if 2 and 3 is not called ... [22:32] further: how to handle gaps/empty slots ... [22:32] how are gaps/empty slots handled in your modell? [22:33] you can't create them ... [22:33] you can only use 0 <= N <= (M+1) [22:33] where M is the 'current' number of slots ... [22:33] you can; you are specifying a slot-id [22:33] your syscall will be rejected if >= (M+1) or NB_IPV4ROOT [22:34] sorry > (M+1) or >= NB_IPV4ROOT [22:34] you can call 'set_ipv4_root(0, &foo); set_ipv4_root(2, &bar)' which leave slot 1 empty [22:34] nope, second is rejected ... [22:35] for what do you need an id then? [22:35] you can change an existing entry if you like ... [22:36] or you can reduce the set afterwards ... [22:37] but we can drop that ...if you want [22:37] what are your future plans for the ip-stuff [22:37] ? [22:38] we add a completely virtual network interface ... [22:38] where you allow addresses and configure from the inside ... [22:39] for userspace, both methods are not making a difference [22:39] (static NB_IPV4ROOT slots, or dynamic allocation) [22:39] but setting broadcast should be splitted into an own syscall [22:40] it does not make sense to transmit the same value 16 times [22:40] I hope we do not transfer 16 ip's anyway ... [22:43] ok; when using static slots, I would prefer a magic value (e.g. -1) for 'id' which means the next slot [22:45] okay we can do that ... [22:47] should we keep the proc infor stating the syscall number? [22:48] does not make sense anymore IMO [22:48] okay, my opinion too .. [22:49] other information should be kept for now until the corresponding get* syscalls are existing [22:50] yes, of course, I'll just remove the syscall number info .. [23:01] there, sent just over a dozen janitorial patches to marcelo [23:01] ;) [23:01] so pre8 will be released soon ;) [23:02] that'd be cool [23:07] @riel any news on the CKRM front? [23:14] not really [23:15] havent read a posting on the list for a while ... [00:00] --- Tue Oct 14 2003