Re: How to disallow logout

[Evan Geller]

Perhaps you could write something to wrap your shell... basically you
could set your login shell to this wrapper. First thing the wrapper
would do is exec and wait on the shell, and when the shell exits,
check what needs to be checked, and should any of these checks fail,
respawn the shell and dump the user back into their login shell. That
way you can't neglect any funky corner cases of the shell exiting...
the shell exits, the checks happen.

In this example, the user is forced to exit 3 times. The experience is
pretty seemless, the only issue is that the user will lose their
environment after failing and ending up back in the new respawned
shell, but I don't see how this would be an issue if the user is
hastefully logging out.

shell-A$ for i in 1 2 3; do bash; echo poop; done
child-1-of-A$ exit
exit
poop
child-2-of-A$ exit
exit
poop
child-3-of-A$ exit
exit
poop
shell-A$ exit
exit
parent-of-A% exit

E

On Thu, Sep 9, 2010 at 8:34 PM, Atom Smasher a...@smasher.org wrote:
 On Thu, 9 Sep 2010, Aryeh Friedman wrote:

 I have a directory that must not exist on logout and rm -rf is not
 sufficent to do it because the contents need to be processed by our version
 control system.

 =

 what i would do... make an alias or function of logout and/or exit in
 the init file that's parsed when the shell starts. alias it to a script or
 assign it to a function that does what you need.

 if your shell supports logging out with ^D (or any other keybinding) then
 the details may be shell-specific, but the idea would be to either disable
 it, or bind it to the script.


 --
        ...atom

  
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -

        The reasonable man adapts himself to the world; the
         unreasonable one persists in trying to adapt the world to
         himself. Therefore all progress depends on the
         unreasonable man.
                -- George Bernard Shaw

 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org




-- 
---
Evan Geller
thes...@gmail.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Recursion in the UVA

[Evan Geller]

I'm a bit confused how recursion in the UVA works. vm_map_entries are
allocated from a vm_map_entry zone, but if the vm_map_entry slabs are
full and it needs to allocate a vm_map_entry to satisfy the mapping,
there would seem to be a starvation. I also see a uk_recurse field per
keg that gets increased when calling back in... but I don't exactly
understand what goes on after the NULL is returned. I'm also a bit
confused about the difference between a keg, a zone, and a slab... the
classic definition of the slab is the per-object cache with slabs...
I'm having trouble understanding what the 3 level structure gets you.

-- 
---
Evan Geller
thes...@gmail.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Recursive case in uma?

[Evan Geller]

Hey, I'm writing a small hobby operating system and I'm looking to the UMA
for inspiration. The part I don't understand is the recursive case in
uma_zone_slab(). I'm curious where the memory for vm_map_entries actually
come from if the slabs are all full. It would appear that the null returned
by uma_zone_slab() just carries all the way up and there's a fixed upper
limit of vm_map_entries... or that I don't understand the way the uma works.
Would someone mind clearing this up for me?

Thanks a ton for the help!
Evan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]