Hardware interrupts in linux

What are software and hardware interrupts, and how are they processed?

On the other hand, I think the purpose of a software interrupt is for a process currently running on a CPU to request some resources.

What are the resources? Are they all in the form of running processes? For example, do CPU driver process and memory driver processes represent CPU and memory resources? Do the driver process of the I/O devices represent I/O resources? Are other running processes that the process would like to communicate with also resources?
If yes, does a software interrupt contact the processes (which represent the resources) indirectly via the kernel process? Is it right that unlike a hardware interrupt, a software interrupt never directly interrupts the CPU, but instead, it interrupts/contacts the kernel process?

A hardware interrupt is not really part of CPU multitasking, but may drive it.

Hardware interrupts are issued by hardware devices like disk, network cards, keyboards, clocks, etc. Each device or set of devices will have its own IRQ (Interrupt ReQuest) line. Based on the IRQ the CPU will dispatch the request to the appropriate hardware driver. (Hardware drivers are usually subroutines within the kernel rather than a separate process.)
The driver which handles the interrupt is run on the CPU. The CPU is interrupted from what it was doing to handle the interrupt, so nothing additional is required to get the CPU’s attention. In multiprocessor systems, an interrupt will usually only interrupt one of the CPUs. (As a special cases mainframes have hardware channels which can deal with multiple interrupts without support from the main CPU.)
The hardware interrupt interrupts the CPU directly. This will cause the relevant code in the kernel process to be triggered. For processes that take some time to process, the interrupt code may allow itself to be interrupted by other hardware interrupts. In the case of timer interrupt, the kernel scheduler code may suspend the process that was running and allow another process to run. It is the presence of the scheduler code which enables multitasking.

Software interrupts are processed much like hardware interrupts. However, they can only be generated by processes which are currently running.

Typically software interrupts are requests for I/O (Input or Output). These will call kernel routines which will schedule the I/O to occur. For some devices the I/O will be done immediately, but disk I/O is usually queued and done at a later time. Depending on the I/O being done, the process may be suspended until the I/O completes, causing the kernel scheduler to select another process to run. I/O may occur between processes and the processing is usually scheduled in the same manner as disk I/O.
The software interrupt only talks to the kernel. It is the responsibility of the kernel to schedule any other processes which need to run. This could be another process at the end of a pipe. Some kernels permit some parts of a device driver to exist in user space, and the kernel will schedule this process to run when needed. It is correct that a software interrupt doesn’t directly interrupt the CPU. Only code that is currently running code can generate a software interrupt. The interrupt is a request for the kernel to do something (usually I/O) for running process. A special software interrupt is a Yield call, which requests the kernel scheduler to check to see if some other process can run.

For I/O requests, the kernel delegates the work to the appropriate kernel driver. The routine may queue the I/O for later processing (common for disk I/O), or execute it immediately if possible. The queue is handled by the driver, often when responding to hardware interrupts. When one I/O completes, the next item in the queue is sent to the device.
Yes, software interrupts avoid the hardware signalling step. The process generating the software request must be a currently running process, so they don’t interrupt the CPU. However, they do interrupt the flow of the calling code. If hardware needs to get the CPU to do something, it causes the CPU to interrupt its attention to the code it is running. The CPU will push its current state on a stack so that it can later return to what it was doing. The interrupt could stop: a running program; the kernel code handling another interrupt; or the idle process.