24 messages in org.freebsd.freebsd-archMPSAFE TTY schedule| From | Sent On | Attachments |
|---|---|---|
| Ed Schouten | Jul 2, 2008 7:08 pm | |
| Takahashi Yoshihiro | Jul 3, 2008 1:49 pm | |
| Ed Schouten | Jul 3, 2008 8:52 pm | |
| Sam Leffler | Jul 3, 2008 9:41 pm | |
| Marcel Moolenaar | Jul 4, 2008 1:49 am | |
| Peter Jeremy | Jul 4, 2008 2:21 am | |
| Ed Schouten | Jul 4, 2008 9:22 am | |
| Peter Wemm | Jul 4, 2008 9:41 am | |
| M. Warner Losh | Jul 4, 2008 12:32 pm | |
| M. Warner Losh | Jul 4, 2008 12:36 pm | |
| M. Warner Losh | Jul 4, 2008 12:36 pm | |
| Takahashi Yoshihiro | Jul 4, 2008 1:12 pm | |
| Coleman Kane | Jul 4, 2008 2:57 pm | |
| Marcel Moolenaar | Jul 4, 2008 7:42 pm | |
| Marcel Moolenaar | Jul 4, 2008 7:50 pm | |
| Takahashi Yoshihiro | Jul 5, 2008 12:25 pm | |
| Marcel Moolenaar | Jul 5, 2008 4:04 pm | |
| Bruce Evans | Jul 6, 2008 3:04 pm | |
| Peter Jeremy | Jul 7, 2008 8:43 am | |
| Ed Schouten | Jul 8, 2008 2:16 pm | |
| Ed Schouten | Jul 13, 2008 7:22 am | |
| Ed Schouten | Jul 20, 2008 12:34 pm | |
| Giorgos Keramidas | Jul 20, 2008 6:46 pm | |
| Ed Schouten | Aug 8, 2008 3:55 am |
| Subject: | MPSAFE TTY schedule | |
|---|---|---|
| From: | Peter Jeremy (pete...@optushome.com.au) | |
| Date: | Jul 7, 2008 8:43:18 am | |
| List: | org.freebsd.freebsd-arch | |
On 2008-Jul-02 21:09:01 +0200, Ed Schouten <ed...@80386.nl> wrote:
+ The new pseudo-terminal driver is capable of garbage collecting unused PTY's. Because PTY's are never recycled, they are a lot more robust (they are always initialized the same, no need to revoke() them before usage, etc).
When you say 'never recycled', does this include the PTY number? If so, long running busy systems are going to get some fairly large numbers. When will the PTY number wrap? What is the impact on tools (eg ps, w) that assume they can represent a PTY in a small number of digits? What about utmp(5) which uses PTY number in the index?
- Not all drivers have been ported to the new TTY layer yet. These drivers still need to be ported: sio(4), cy(4), digi(4), ubser(4), uftdi(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4), rc(4), si(4), umodem(4), dcons(4).
Even though drivers are very important to have, I am convinced we can get these working not long after the code as been integrated. ... If you really care about one of these drivers, please port it to the new TTY layer as soon as possible!
IMHO, this is not a reasonable approach: "Hi everyone. I'm going to break infrastructure that a whole bunch of drivers depend on. If you don't fix your drivers in the next few weeks then I'll disconnect them". Either you need to provide compatibility shims (possibly temporary and not MPSAFE) or you need to be far more pro-active in assisting with porting existing consumers of the TTY layer.
TTY layer into our kernel. I would really appreciate it if I could get this code in before the end of the summer break, because I've got heaps of spare time to fix any problems then.
That's all very nice but what about the maintainers of all the other drivers that you are impacting?
sio(4) has not been ported to the new TTY layer and is very hard to do so.
This is the only mention of how much effort is involved in porting a driver to use the MPSAFE TTY layer and "very hard" is not a good start. I can't quickly find any documentation on how to go about porting an existing driver - definitely there are no section 9 man pages describing the new API in your patchset.
IMHO, if you can't commit fixed drivers along with the MPSAFE TTY layer, a more reasonable schedule is to replace the existing TTY layer with an MPSAFE TTY layer that includes compatibility shims. If the shims make things non-MPSAFE (which is likely) then warn that they will be going away in (say) six months. This gives developers a more reasonable timeframe in which to update, as well as working drivers whilst they adapt them.
-- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour.