View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002409 | unreal | ircd | public | 2005-03-07 22:39 | 2015-05-27 18:09 |
| Reporter | w00t | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.4-alpha3 | ||||
| Summary | 0002409: Stuff in core that could be moved to modules (pwease?) | ||||
| Description | I was wondering, if a number of currently core features (such as umode +W, snomask k, etc) could be moved to modules. I've created something functionally equivilant to +W (with a different umode) if you want it. As for snomask k, couldn't that be moved to the kill module? why do we need a kill snomask, when we may not have a kill module loaded? :p | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Well, in theory what you suggest sounds good. However, there are still some "issues" with the umode/snomask system with modules. The modules technically need to be marked as permanent. I really don't want to do that with core modules as it defeats the purpose of modules -- hotfixes. However, in the future, once these issues are fixed, this sounds like a good idea. Umode W logically goes with m_whois and Snomask k goes with m_kill, I'm sure there are others as well. If you have any suggestions as to how to save the state of umodes/snomasks during a rehash, I'm certainly willing to listen! |
|
|
I don't suppose it'd be possible to create another state, sort of.. permanent except on upgrade? Naturally I know next to nothing about how the Unreal modules system works. I'll try have a look over the next few weeks/months/years (:/) and see what I can come up with. |
|
|
Well, that's a possibility I never really considered. We could, I suppose, store an MD5 and only reload if the MD5s don't match... Syzop, do you have any comments on that idea? |
|
|
There's still the issue with preserving state in the event a module *is* upgraded. However, in most cases it only affects that module, and the user/channel modes, etc that are defined within. The problem: when a single official command module is upgraded (eg, the 3.2.2b patch), commands.so would become "upgraded" as well, and most everyone uses commands.so so EVERYTHING in commands.so (not just the affected bits) gets thwapped. Maybe this is just another beef against having a mondomodule like commands.so? I suppose that could be addressed though if commands.so just marked all the official seperate .so modules as a dependency (instead of static-linking them, but that's grounds for a seperate issue/whatever), causing them to be loaded and probably treated as seperate modules and so on, but would they then be listed in /module as well (eg, 30000000 lines in /module just from the official modules :x )... Still... non-permanent modules would need a way to preserve data through a rehash in the event that they are upgraded, but this would be a different issue (and in fact, is already posted somewhere here on the bug tracker)... |
|
|
Yeah, I'm not saying it is a solution, but it's a step in the right direction. |
|
|
Yes.. isn't this umodes/snomasks reloading thing quite easy? I mean, I thought all we needed to do is tag the umode as 'due to be deleted', then when we load the new mods they can take that umode entry again (and receive the existing umode value [eg: 0x2000])... if no modules added the mode, then we can safely delete it (send out an umode -<blah> to everyone etc etc). Same for single char extcmodes and also extbans, as you know.. the only problem I cannot easily think of a solution of is parameter stuff, but the rest should be easy.. AFAICT :). Actually.. I thought we had code that did this (tag, &check if nobody requested it after [re]loading everything), but that there was some kind of bug -- 0001855 [private bug] ** w00t: On a sidenote, not loading the KILL module is not something we would support, things like nick collisions and other issues require it, it's not simply only for opers or anything. Just like, I don't see why you would want a network without /whois, I've only seen people running drone servers requesting that (no I'm not suggesting that you... ;p). Also if you completely replace something like the whole kill command and whois command with 3rd party code then IMO that isn't too far of modified code... That reminds me of a module angrywolf made once, I forgot which, but anyway: he copied 400 lines of the main code for the command to his module, added his own code somewhere in-between and then completely "overwrote" the command with his handler (and never calling the original), perhaps technically that's not modifying of code, but in practice there's no difference at all with THAT or adding the 30 lines of his own code to the source. I don't think we should support that kind of stuff, what do you think codemastr? Then again, we are already free to say stuff isn't supported if any 3rd party module is present so I don't know why I'm writing this ;). |
|
|
Well, originally that was the idea. Then I got to thinking... consider: SomeMod creates snomask +A /rehash SomeMod is unloaded SomeMod2 creates snomask +A Now the users remain +A but SomeMod2 might have some completely different purpose for +A, perhaps it is now oper-only. Meaning, we need some way to keep track of "who" created the snomask last time and see if it is still the same. |
|
|
True, but we could for example store the name of the module (well not the tmp name). That said, I don't think it's too common, I think having the just proposed system vs permanent modules would already make it a lot nicer (and then, with the name system you might have it all solved). |
|
|
yeah storing the name would solve it... That'll make umodes/snomasks work fine on /rehash. Also about m_kill, I agree that should never be unloaded (afaik it can't be?) but still, having the Snomask defined in there seems logical. |
|
|
Yup :). |
|
|
w00t: On a sidenote, not loading the KILL module is not something we would support, things like nick collisions and other issues require it, it's not simply only for opers or anything. ----------- It was merely an example :p The rest of the snomasks really are just as valid. Say, if /spamfilter ever became a module, and i didn't want it... I'd sure as hell want that snomask free ;) Just like, I don't see why you would want a network without /whois, I've only seen people running drone servers requesting that (no I'm not suggesting that you... ;p). ----------- Missed what I said a *little* I may have misworded it. I meant, why is umode +W in the core code, and not implemented via a module (yet another example). It'd be easy to implement (i've already done so, and made it all user-settable. I'll get around to releasing it one day >_>) True, but we could for example store the name of the module (well not the tmp name). ----------- As we're already using MD5 hashes, couldn't we use those? -*edit*- fixed crazy copy/paste crap :| -*edit*- |
|
|
We were not talking about the half-permanent thing anymore w00t... so in that case making an md5sum of the file is several thousand times slower than just getting the name. |
|
|
[quote]so in that case making an md5sum of the file is several thousand times slower than just getting the name.[/quote] Well in reality I'd probably just use a CRC since the odds of two modules having the same CRC is incredibly unlikely... but anyway ;) For 3.2.4 I'll add a system that allows snomasks/umodes to work fine during a rehash. I was also thinking, perhaps there should be some way for a module to say "don't save the state." So I was thinking something like having Mod_Unload return MOD_NOSAVE will force it NOT to record the state of snomasks/umodes (and anything else we might add to this system in the future). |
|
|
[quote=codemastr]Well, originally that was the idea. Then I got to thinking... consider: SomeMod creates snomask +A /rehash SomeMod is unloaded SomeMod2 creates snomask +A Now the users remain +A but SomeMod2 might have some completely different purpose for +A, perhaps it is now oper-only. Meaning, we need some way to keep track of "who" created the snomask last time and see if it is still the same. [/quote] Ok, I don't really know alot about the module api (next to nothing), but to solve the part about +A being operonly (in the example above), you could do this: SomeMod creates snomask +A SomeUser sets snomask +A SomeOper sets snomask +A SomeOper /rehash SomeMod is unloaded Unreal sets snomask -A on SomeUser Unreal sets snomask -A on SomeOper SomeMod2 is loaded SomeMod2 creates snomask +A (oper only) Unreal tells SomeMod2 that SomeUser tries to set snomask +A SomeMod2 tells SomeUser that it is an oper-only snomask Unreal tells SomeMod2 that SomeOper tries to set snomask +A SomeMod2 sets SomeOper snomask +A |
|
|
Another thing that can be module-ized is allow-part-if-shunned - a very easy one too. (In ModLoad: | in an (ALLOW_PART_IF_SHUNNED ? M_SHUN : 0)) |
|
|
I had a talk to Stskeeps the other day about metadata, which would make it a lot easier for stuff (like jointhrottle) to be moved to modules. I might be able to tack that conversation on here later (or maybe he could) - if not, I'll try clarify tomorrow. |
|
|
I presume we are now talking about "moving stuff to modules" (and not the module-state problems, which are technically solvable)... There are several possiblities how far with modules you want to go: 1. Modulize as much routines as possible, like we currently are doing, actually we can modulize even more.. the efunctions stuff I wrote is a nice base that can be used to modulize even more (non-command) core routines. 2. Same as above, but also put features/umodes/whatever in different modules. I got the feeling '2' sparks the interest of quite some people (possibly, rightfully so). But before choosing that, have you guys actually looked at the downsides of such a decission? PRO's: - User can customize the ircd by removing modes or certain features CON's: - Slower (between module jumps ["outsourcing"] or hooking is always slower) - If you don't think too much you might say "wow, that must be much more clearer.. All code of feature A goes in A, wonderful!", but it can in fact easily be the total opposite: it can get quite messy, think about the practical way to implement this: things like operoverride in a module... how would you implement that technically? Let's take some (more simpler) examples, to see how you technically would do things.. umode +W, you wouldn't want to make it a simple cmdoverride and parse the targets again since that's a waste, you probably want a hook that calls a module on every targetted user whois. Luckely since CVS we canonize() the target list because otherwise the mod would even have to maintain a remember-if-"did I send my '.. did a whois on you'"-message-got-sent-already. So anyway, that's easy. Umode +d (deaf)? Quite easy, just a pre_message hook or something that returns 1/0. Umode +i? This is what I would call a core feature, I don't think such RFC1459 modes should be modulized. It also would be a complete mess, actually... think about modulizing things like +s.. wouldn't that be crazy? (topic, who, whois, list, webtv whois) Umode / Chanmode +G: Easy Umode +T / chmode +C: Easy [etc] How about umode +B ('is a bot').. How would you modulize that.. A whois hook? And when would that be called? Since order of whois is important. Or would it be called after every line? How much impact would that have? Umode +V (webtv)? Currently crazy.. We got 46 IsWebTV() calls in the source. Though many (but not all) of these are .. ? "PRIVMSG" :"NOTICE" things which can be replaced by my simple sendnotice().. And then.. would you want to have a seperate sendnotice depending on webtv? or how would you implement it? [more] As you can see quite some things are quite possible, and via hooks, sure.. I think they would be fast enough. My only comment is: don't blindly modulize stuff that is too "build-in" or would have too much CPU impact. Nor do things like the idiotic modulizing of invisibility was, which was not true modulization at all. So basically: keep it realistic. Also some more research would be needed about CPU impact. This is not my only concern though (say, a 5-10% cpu degradation after a lot has been modulized) is acceptable to me, computers are fast these days, I'm more concerned by the "readability" of the source. aquanight: I, for example, don't see any reason why you would want to modulize that: sure it is possible but it gives NO practical benefit, that is indeed exactly what I mean with overmodulizing. Opinions from others (Stskeeps?) are appreciated on issues like this (and my whole story of above, of course). |
|
|
On the subject of modules adding stuff to the /whois reply ... It would be rather neat if there was some way that modules could say "if user is mode +6 then send message XXX" Seperating code in to smaller chunks for the sake of it feels like making work for works sake hehe. |
|
|
Yes, this is largely what I meant, and I agree with you pretty much totally syzop :p. It also reduces the memory footprint in (some) cases where people don't want some stuff loaded (like personally I don't use jointhrottle, so I wouldn't load it, meaning there'd be no trace of it - where as in the present system, the crap is still in each struct, so you still get the memory load. 1) is good, and something I've been looking at.. Personally I think something that *will* need reviewing is the umode code (not looked at channel stuff yet) - I was trying to work on the whole +xt virthost issue, and got hopelessly confused/wasn't able to do it cleanly.. so modules are going to have the same (worse) issues there. How I'd implement? Not having too much experience with such a system (beyond atheme) I'd probably use hooks, and other fun things. This may, or may not be a good way to do it though. (With a lot of hooks, things would start to get a bit ######.) Good point about whois, and it's an interesting point to raise given I did allwhois ;p. I've got to run, but I'll think some more on this.. hope I've made sense, since I've been whacking this all out quickly. |
|
|
On the other hand, I've realised this is (kind-of) getting a little off topic. Feel free to tell me to stfu/start a second issue ;) |
|
|
We've modularized tons of stuff like this to modules in 3.4-alpha*. It's still an ongoing process as more and more will be moved but really a lot has been moved now (major goal for 3.4). Ok, it only has been 10 years :D |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-03-07 22:39 | w00t | New Issue | |
| 2005-03-07 22:43 |
|
Note Added: 0009489 | |
| 2005-03-07 23:05 | w00t | Note Added: 0009491 | |
| 2005-03-07 23:18 |
|
Note Added: 0009492 | |
| 2005-03-07 23:34 | aquanight | Note Added: 0009493 | |
| 2005-03-07 23:39 |
|
Note Added: 0009494 | |
| 2005-03-07 23:44 | syzop | Note Added: 0009495 | |
| 2005-03-07 23:48 |
|
Note Added: 0009497 | |
| 2005-03-07 23:52 | syzop | Note Added: 0009498 | |
| 2005-03-07 23:55 |
|
Note Added: 0009500 | |
| 2005-03-07 23:56 | syzop | Note Added: 0009501 | |
| 2005-03-08 09:31 | w00t | Note Added: 0009515 | |
| 2005-03-08 09:32 | w00t | Note Edited: 0009515 | |
| 2005-03-08 11:11 | syzop | Note Added: 0009523 | |
| 2005-03-08 11:17 |
|
Note Added: 0009524 | |
| 2005-03-11 14:52 | Cobi | Note Added: 0009562 | |
| 2005-03-11 17:40 | Cobi | Note Edited: 0009562 | |
| 2005-11-06 21:54 | aquanight | Note Added: 0010657 | |
| 2005-11-07 02:01 | w00t | Note Added: 0010658 | |
| 2005-11-07 09:29 | syzop | Note Added: 0010659 | |
| 2005-11-07 20:58 | Nazzy | Note Added: 0010661 | |
| 2005-11-08 00:14 | w00t | Note Added: 0010663 | |
| 2005-11-08 01:34 | w00t | Note Added: 0010664 | |
| 2007-04-18 06:10 |
|
Status | new => acknowledged |
| 2015-05-27 18:09 | syzop | Note Added: 0018350 | |
| 2015-05-27 18:09 | syzop | Status | acknowledged => resolved |
| 2015-05-27 18:09 | syzop | Fixed in Version | => 3.4-alpha3 |
| 2015-05-27 18:09 | syzop | Resolution | open => fixed |
| 2015-05-27 18:09 | syzop | Assigned To | => syzop |
