The assertion is there because in most cases tsleep will mean a mid to long term wait. It could be make OK to use but the assertion seems more valuable. Andrew

However you turn it - you initiate a USB transaction and you want to wait for its result. This can take a while, so you have to wait. Whether USB uses an own thread internally or not changes only who is going to wake you up. In any case Whai I say "mixed" I'm talking about semantics and terms, and implementation. I'm not assuming that they happen at the same time and that this might cause problems. The suspend/resume functions as done now are primarily to get the machine to sleep -S3 in ...

[I'm copying this from source-changes because I believe the discussion deserves a wider audience, and a better subject heading. :-)] Do the legacy shutdown hooks hang, or do the PMF suspend routines hang? I thought that it was the latter. That is why I suggest the more conservative change: skip PMF suspension if there was a panic, but let the shutdown hooks run. Will you give examples of the drivers that do not implement polling correctly, so that people can fix them? You have also ...

Hi, I have a patch to make a large portion of the network code use a new "struct sockopt" (inspired by similar work done in FreeBSD, with input from dyoung@ and yamt@) instead of passing socket options in mbufs. The work is incomplete - although I think the majority of the code was covered. I've been running it here for about a month or so, but I'm putting it up for public review as it's unlikely I'll be able to test all of the code paths affected by these changes, specifically in network ...

hi elad, could you explain what the purpose/benefit of this is? thanks, .mrg.

so_setsockopt: Shouldn't valsize be the normal size_t? Does socklen_t really make sense here? The val pointer should be const. sockopt_ensure_writeable --> I don't like the name. If you can now also push the socket options down into ipv4/ipv6 and the patch can go without the sockopt_setmbuf/getmbuf, that would be very nice :-) Without a full review, this looks like a huge improvement. Joerg

Instead of passing "struct mbuf" for everything (socket options, various socket addresses, etc.) I'd like to -- like done in FreeBSD over 10 years ago -- use (the) proper types for everything. -e.

One problem here is that the compat code probably doesn't want to call the sys_foo() function itself, but rather then next function down that is executed once all the parameters are in kernel space. I think that means that if sys_foo() is in an LKM, then compat_bar_sys_foo() must also be in an LKM. Then the LKM dependecies can be used to ensure all the required functionality is present. David -- David Laight: david@l8s.co.uk

Found the problem, on my target. It was not a uvm problem at all, but some other unrelated issue that happened to scribble on the freelist.