Translation status
| 2,721 | Strings | 91% | Translate |
|---|---|---|---|
| 69,331 | Words | 84% |
Other components
| Component | Translated | Untranslated | Untranslated words | Checks | Suggestions | Comments | |
|---|---|---|---|---|---|---|---|
articles_cups
BSD-2-Clause-FreeBSD
|
0% | 48 | 1,544 | ||||
|
|
|||||||
|
articles_serial-uart
BSD-2-Clause-FreeBSD
|
0% | 468 | 9,234 | ||||
|
|
|||||||
|
articles_explaining-bsd
BSD-2-Clause-FreeBSD
|
0% | 90 | 3,100 | ||||
|
|
|||||||
|
articles_building-products
BSD-2-Clause-FreeBSD
|
0% | 194 | 3,381 | ||||
|
|
|||||||
|
articles_committers-guide
BSD-2-Clause-FreeBSD
|
0% | 977 | 21,168 | ||||
|
|
|||||||
|
articles_contributing
BSD-2-Clause-FreeBSD
|
0% | 217 | 5,622 | ||||
|
|
|||||||
|
articles_contributors
BSD-2-Clause-FreeBSD
|
0% | 3,507 | 14,348 | ||||
|
|
|||||||
|
articles_freebsd-questions
BSD-2-Clause-FreeBSD
|
0% | 94 | 3,147 | ||||
|
|
|||||||
|
articles_geom-class
BSD-2-Clause-FreeBSD
|
0% | 149 | 3,062 | ||||
|
|
|||||||
|
articles_ipsec-must
BSD-2-Clause-FreeBSD
|
0% | 44 | 1,084 | ||||
|
|
|||||||
Translation Information
| Project website | wiki.freebsd.org/DocTranslationOnWeblate |
|---|---|
| Mailing list for translators | freebsd-translators@freebsd.org |
| Instructions for translators | |
| Translation process |
|
| Translation license | BSD-2-Clause-FreeBSD |
| Filemask | books/*/arch-handbook.po |
| Translation file |
books/zh_CN/arch-handbook.po
|
dbaio
None
Example: Firmware download Many devices that have been developed are based on a general purpose processor with an additional USB core added to it. BecausSince the development of drivers and firmware for USB devices is still very new, many devices require the downloading of the firmware after they have been connected.
The poll function is used to simulate the interrupts when the interrupt subsystem is not functioning (for example, when the system has crashed and is creating the system dump). The CAM subsystem sets the proper interrupt level before calling the poll routine. So all it needs to do is to call the interrupt routine (or the other way around, the poll routine may be doing the real action and the interrupt routine would just call the poll routine). Why bother about a separate function then? Because ofDue to different calling conventions. The <function>xxx_poll</function> routine gets the struct cam_sim pointer as its argument when the PCI interrupt routine by common convention gets pointer to the struct <varname remap="structname">xxx_softc</varname> and the ISA interrupt routine gets just the device unit number. So the poll routine would normally look as:
That is all for the ABORT request, although there is one more issue. BecauseAs the ABORT message cleans all the ongoing transactions on a LUN we have to mark all the other active transactions on this LUN as aborted. That should be done in the interrupt routine, after the transaction gets aborted.
If the CCB is being transferred right now we would like to signal to the SCSI controller in some hardware-dependent way that we want to abort the current transfer. The SCSI controller would set the SCSI ATTENTION signal and when the target responds to it send an ABORT message. We also reset the timeout to make sure that the target is not sleeping forever. If the command would not get aborted in some reasonable time like 10 seconds the timeout routine would go ahead and reset the whole SCSI bus. BecausSince the command will be aborted in some reasonable time we can just return the abort request now as successfully completed, and mark the aborted CCB as aborted (but not mark it as done yet).
Then allocate and activate all the necessary resources. BecauseAs normally the port range will be released before returning from probe, it has to be allocated again. We expect that the probe routine had properly set all the resource ranges, as well as saved them in the structure softc. If the probe routine had left some resource allocated then it does not need to be allocated again (which would be considered an error).
Before calling the callback function from <function>bus_dmamap_load()</function> the segment array is stored in the stack. And it gets pre-allocated for the maximal number of segments allowed by the tag. BecauseAs a result of this the practical limit for the number of segments on i386 architecture is about 250-300 (the kernel stack is 4KB minus the size of the user structure, size of a segment array entry is 8 bytes, and some space must be left). BecausSince the array is allocated based on the maximal number this value must not be set higher than really needed. Fortunately, for most of hardware the maximal supported number of segments is much lower. But if the driver wants to handle buffers with a very large number of scatter-gather segments it should do that in portions: load part of the buffer, transfer it to the device, load next part of the buffer, and so on.
Statistics
| Percent | Strings | Words | Chars | ||
|---|---|---|---|---|---|
| Total | 2,721 | 69,331 | 560,593 | ||
| Translated | 91% | 2,486 | 58,735 | 479,062 | |
| Needs editing | 1% | 42 | 1,589 | 11,546 | |
| Failing checks | 31% | 853 | 16,524 | 187,857 |
Last activity
| Last change | Nov. 24, 2020, 2:51 a.m. | |||
|---|---|---|---|---|
| Last author | Guangyuan Yang | |||