search

smack-team / smack

Smack userspace
GNU Lesser General Public License v2.1
41 stars 33 forks source link

libsmack 1.1: support for load-self #101

Open jarkkojs opened 10 years ago

jarkkojs commented 10 years ago

I think it would make sense to add functions for load-self to 1.1 release.

jobol commented 10 years ago

On lun, 2014-03-17 at 23:50 -0700, jsakkine wrote:

I think it would make sense to add functions for load-self to 1.1 release.

I agree!

I'm currently working on a smack-launcher using that interface. https://github.com/jobol/smaunch

José

PS: I made some smack-utils specific development for it using a different way of thinking. The object is not to fork but to explore...

— Reply to this email directly or view it on GitHub.

jarkkojs commented 10 years ago

On Tue, Mar 18, 2014 at 12:14:49AM -0700, jobol wrote:

On lun, 2014-03-17 at 23:50 -0700, jsakkine wrote:

I think it would make sense to add functions for load-self to 1.1 release.

I agree!

I'm currently working on a smack-launcher using that interface. https://github.com/jobol/smaunch

OK, great. I though that it could be useful addition and I also suggest creating issues for other things that might be useful for the API.

José

/Jarkko

jarkkojs commented 10 years ago

I would add a new function smack_accesses_apply2 with a flags parameter so that in future there's more resistance to API additions.

jobol commented 10 years ago

good idea, I approve

rafal-krypa commented 10 years ago

That name may suggest, that it uses load2 kernel interface. How about smack_accesses_apply_new or smack_accesses_apply_ng? 21 mar 2014 07:15 "jsakkine" notifications@github.com napisał(a):

I would add a new function smack_accesses_apply2 with a flags parameter so that in future there's more resistance to API additions.

— Reply to this email directly or view it on GitHubhttps://github.com/smack-team/smack/issues/101#issuecomment-38251577 .

jobol commented 10 years ago

I dont feel that the ambiguity is very high between apply2 and load2 but I admit that it exists an ambiguity. It makes me think that if smack_accesses_apply becomes deprecated the transition to using smack_accesses_apply2 or smack_accesses_apply_ng might be a nightmare. Maybe a better choice would be to use a very different name like smack_accesses_assign or smack_accesses_execute or ....

jobol commented 10 years ago

I got an other idea: using special (negatives) fd in smack_accesses_save would allow to remove any apply. Special values for fd could be:

and also values for specific interface

Also in that case the name smack_accesses_writemay better fit.