src/sys/dev/snp, branch release/8.1.0

Keep this line shorter than 80 columns.

2009-05-13T19:29:50Z

Add macros around the sx operations in snp(4).

2009-05-11T18:52:46Z

As an experiment, I changed snp(4) to use a mutex instead of an sx lock. We can't enable this right now, because Syscons still picks up Giant. It's nice to already have the framework there.

Slightly improve the design of the TTY buffer.

2009-02-03T19:58:28Z

The TTY buffers used the standard lists. Unfortunately they have a big shortcoming. If you want to have a double linked list, but no tail pointer, it's still not possible to obtain the previous element in the list. Inside the buffers we don't need them. This is why I switched to custom linked list macros. The macros will also keep track of the amount of items in the list. Because it doesn't use a sentinel, we can just initialize the queues with zero. In its simplest form (the output queue), we will only keep two references to blocks in the queue, namely the head of the list and the last block in use. All free blocks are stored behind the last block in use. I noticed there was a very subtle bug in the previous code: in a very uncommon corner case, it would uma_zfree() a block in the queue before calling memcpy() to extract the data from the block.

Change ttyhook_register() second argument from thread to process pointer.

2008-12-13T21:17:46Z

Thread was not really needed there, while previous ng_tty implementation that used thread pointer had locking issues (using sx while holding mutex).

Reintroduce the snp(4) driver.

2008-11-05T15:04:03Z

Because the TTY hooks interface was not finished when I imported the MPSAFE TTY layer, I had to disconnect the snp(4) driver. This snp(4) implementation has been sitting in my P4 branch for some time now. Unfortunately it still doesn't use the same error handling as snp(4) (returning codes through FIONREAD), but it should already be usable. I'm committing this to SVN, hoping someone else could polish off its rough edges. It's always better than having a broken driver sitting in the tree.

Even though snp(4) in SVN is still broken, remove the unneeded D_NEEDMINOR.

2008-09-19T10:21:30Z

kib@ and I have decided we will MFC the bpf(4)/snp(4) fixes after we've released 7.1. Make sure the code in HEAD doesn't refer to a flag we don't need anyway. snp(4) in the MPSAFE TTY P4 branch already works, but still needs some polishing before it can be integrated to SVN.

Convert the snp(4) driver to use cdevpriv.

2008-08-15T13:07:07Z

Now we have a single /dev/snp device node, which can be opened by watch(8) multiple times. Even though snp(4) will be dead as of next week, it's nice having this in SVN, because: - We may want to MFC it to RELENG_7. - By the time we fix snp(4) again, it's already there, existing watch(8) binaries should already work. Just like bpf(4), I'm adding a symlink from snp0 to snp to remain binary compatible.

Don't enforce unique device minor number policy anymore.

2008-06-11T18:55:19Z

Except for the case where we use the cloner library (clone_create() and friends), there is no reason to enforce a unique device minor number policy. There are various drivers in the source tree that allocate unr pools and such to provide minor numbers, without using them themselves. Because we still need to support unique device minor numbers for the cloner library, introduce a new flag called D_NEEDMINOR. All cdevsw's that are used in combination with the cloner library should be marked with this flag to make the cloning work. This means drivers can now freely use si_drv0 to store their own flags and state, making it effectively the same as si_drv1 and si_drv2. We still keep the minor() and dev2unit() routines around to make drivers happy. The NTFS code also used the minor number in its hash table. We should not do this anymore. If the si_drv0 field would be changed, it would no longer end up in the same list. Approved by: philip (mentor)

Move the check for the snp device being already attached after the

2007-12-24T13:47:16Z

fget() call, that is sleeping point, and possibly dropping Giant. The snp_target == NULL implies the snp_tty == NULL. Remove the code that is put under snp_target == NULL and snp_tty != NULL clause. In snpclose(), do the snp_detach() before scheduling the snp device destruction. Otherwise, after the return from snpclose(), the snp device is already removed from the snp_list, but tty is still in snooped state. Any attempt to do i/o on such tty cause panic because ttytosnp() returns NULL. Tested by: Peter Holm MFC after: 1 week

Do not allow the SNPSTTY ioctl for the snoop device that has a tty

2007-12-03T14:02:27Z

attached. Otherwise, the snp->snp_tty would be overwritten, while the tty line discipline still set to the snpdisc. Then snplwrite() causes panic because ttytosnp() cannot find the snp. MFC after: 1 week